This chapter identifies features and functionality added to or modified in Releases 12.0, 12.1, and 12.2.
Additional information on the items listed in this chapter is available in the documentation listed in the table below.
|
Cisco ASR 5000 Series Mobility Unified Reporting System Installation and Administration Guide
|
|
Cisco ASR 5000 Series Subscriber Service Controller Installation and Configuration Guide
|
|
Cisco ASR 5000 Series Policy Provisioning Tool Installation and Configuration Guide
|
|
Open Source Software Licenses for Cisco ASR 5000 Series Multimedia Network Core Platform
|
Bearer-Usage AVP Value for Primary/Secondary Contexts - Behavioral Change
In the earlier releases, the Bearer-Usage AVP was encoded with the value GENERAL(0) irrespective of whether the context is primary or secondary in the Diameter Gy CCR message.
In the current release, the Bearer-Usage AVP will be encoded with the value GENERAL(0) for Primary-PDP context/default bearer and with the value DEDICATED(2) for all secondary-PDPs/dedicated bearers.
In the earlier releases, when there were no static rules configured in the chassis and if the PCRF returns a error-result code in CCA-I with CCFH action as continue, then the call was not terminated.
In the current release, P-GW terminates the call even if the static rules are not configured and an error-result code is returned in CCA-I with CCFH action set as continue.
In the earlier releases, CCR-T was sent when a permanent failure result code (5xxx result codes) was received and the Disconnect reason was “ims_auth_decision_invalid”.
In the current release, the call is dropped without sending CCR-T when the permanent failure result code (5xxx result codes) is received and the Disconnect reason will be “ims-authorization-failed”.
In the earlier releases, the configuration of Diameter nodes and host strings like endpoint name, peer name, host name, realm name, and fqdn were case-sensitive. Hence, it was difficult to handshake with an external node with the name specified in a different case. That is, if a peer is configured as peer.cisco.com, it failed to open connections from a peer identifying as PEER.cisco.com. Also, configuring endpoints with different cases duplicate the configuration. For example, when configuring endpoints ep1 and EP1, it will assume it to be different and add these separately in the configuration.
In the current release, all the Diameter related node IDs are considered case insensitive. This change applies to both the local configuration and communication with external nodes. When configuring endpoints s6a-endpoint-mme, S6A-endpoint-MME, S6A-ENDPOINT-MME, all these three will be considered the same.
The maximum character length of Charging Rulebase Name field in LOSDVs of eG-CDRs and P-GW-CDRs is now configurable. This change is now available in 12.0 and later releases.
In earlier releases, in case of Custom5 or Custom40 dictionaries, the rulebase name used to get trimmed to 16 characters. In other dictionaries the complete rulebase name used to appear in the LOSDVs.
A new CLI command now enables to configure maximum length of the rulebase name between 1 through 63 characters. If configured as 0 (zero), the rulebase name is not trimmed. This new CLI command is available at the context and GTPP group levels.
Diameter load balancing implementation maintains a fixed number of servers active at all times for load balancing in case of failures. This can be done by selecting a server with lower weight and adding it to the set of active servers.
|
l
|
Endpoint configuration is needed to specify the minimum number of servers that needs to be active for the service.
|
|
l
|
If any one of the servers in the current active group fails, one of the idle servers needs to be selected for servicing the new requests.
|
eG-CDRs can be in ASN.1 format or in delimiter-separated ASCII format. Configuring the eG-CDR encoding type is a CLI-configurable parameter. The default encoding type is ASN.1. When configuring the eG-CDR encoding type as ASCII, the delimiter character can be specified as either “:” (colon), “,” (comma), or “|” (pipe). The default delimiter character is “|” (pipe).
In the current releases, the Bearer-Usage AVP is sent only during the establishment of bearers in CCR-I and CCR-U with bearer operation as “Establishment”. This condition is imposed because the session level CCR-U is intended for the entire session and not for a particular bearer.
Encoding of Destination-Host AVP in Initial-Request Messages - Behavioral Change
In the earlier releases, the Destination-Host AVP was not sent in session-setup/initial request (first message sent on that interface for that subscriber. This message will vary with different interfaces. For example, CCR-Initial for Gy, ACR-start for Rf, and so on). Also, Destination-Host AVP was not sent in retried requests. For example, CCR-Update failed to be responded by server. The message was retransmitted to alternate server.
In both these scenarios, it is not known which server will respond to the initial/retried message, so the Destination-Realm is encoded but not the Destination-Host. Only after a response for this message is received from one of the hosts present in that realm, the session is considered to be BOUND with that server. Any message sent after this binding will have the Destination-Host AVP encoded.
In the current release, with the CLI command “destination-host avp session binding … ”, if the application has selected one of the servers using application-level commands like peer-select command in case of credit-control or diameter authentication/accounting server command in AAA group, encoding of this AVP in initial/retried request is configurable.
Encoding of Network-Request-Support AVP in CCR Messages - Behavioral Change
In the earlier releases, the Network-Request-Support AVP was sent in CCR-T and session level CCR-U messages.
In the current release, if the network-initiated bearer establishment request procedures are not applicable during IP-CAN session establishment, this AVP will not be encoded in CCR-I and in the subsequent messages unless the AVP value is toggled from 1 to 0 and vice-versa.
If the network-initiated procedures are applicable during IP-CAN session establishment, this AVP will be encoded only in the CCR-I and not in the subsequent messages including session level CCRs unless the AVP value is toggled.
In the earlier releases, the Offline AVP in Gx CCR-I was sent based on the presence of “billing-action egcdr” OR “billing-action rf” configuration within the charging-action of the ECSv2 rulebase chosen for the Diameter Gx session.
In the current release, the Offline AVP in Gx CCR-I is sent based on the mapping of the Charging-Characteristics-Profile (received in the GTPC Create-PDP-Context-Request) to the Offline AVP (the mapping is CLI configurable in the Policy Control Configuration mode).
Encoding of QoS-Upgrade and QoS-Negotiation AVPs in CCR Messages - Behavioral Change
In the earlier releases, the QoS-Upgrade and QoS-Negotiation AVPs were sent in session level updates and in CCR-T message.
In the current release, as the QoS-Upgrade and QoS-Negotiation AVPs are applicable to bearer, these AVPs will no longer be sent in the CCR-U and CCR-T messages.
In the earlier releases, when Supported-Features AVP was encoded for the following dictionaries, the Vendor-Id AVP under the grouped AVP Supported-Features was sent with “M” bit cleared.
In the current release, when the Supported-Features AVP is encoded for the above mentioned dictionaries, the Vendor-Id AVP under Supported-Features AVP is sent with “M” bit set.
In the earlier releases, in the case of failure handling, if the CLI command “failure-handling cc-request-type …” is configured twice under ims-auth-service then the following error message “Failure: Apply config error” is displayed. For example, if the failure-handling configured is “X” and if the same failure-handling “X” is applied again then the error message “Failure: Apply config error” is displayed.
In the current release, if the same failure-handling configuration is applied under IMSA service then the configuration is accepted as valid and it does not throw any error message.
In the earlier releases, on reception of transient failure result-code 4010 at message/root level by DCCA client, CCR-T was not sent to the OCS server when the DCCA session is terminated.
In the current release, when the failure result-code 4010 is received at message/root level and if CCFH is set to terminate/retry-and-terminate action, then the DCCA session is terminated with CCR-T.
More specifically, for the result-code 4010 received in CCA-U, it is expected to send CCR-T and wait for a response before terminating the DCCA session. For the result-code 4010 in CCA-I, the subscriber session is rejected and CCR-T is sent.
This release supports the RADIUS Fire-and-Forget feature in conjunction with GGSN for secondary accounting (with different RADIUS accounting group configuration) to the RADIUS servers without expecting acknowledgement from the server, in addition to standard RADIUS accounting. This secondary accounting will be an exact copy of all the standard RADIUS accounting message (RADIUS Start / Interim / Stop) sent to the standard AAA RADIUS server. For this configuring secondary AAA accounting group for the APN is supported.
This release also supports the No-ACK RADIUS Targets feature in conjunction with PDSN and HA for secondary accounting (with different RADIUS accounting group configuration) to the RADIUS servers without expecting the acknowledgement from the server, in addition to standard RADIUS accounting. This secondary accounting will be an exact copy of all the standard RADIUS accounting message (RADIUS Start / Interim / Stop) sent to the standard AAA RADIUS server. For this configuring secondary AAA accounting group for the subscriber template is supported.
Old behavior: The G-CDR buckets are closed on receiving 4010/4012 message level from the OCS when failure-handling is configured as terminate or retry-and-terminate. The final CDR will have Normal closure as the causeForRecordClosing.
New behavior: The G-CDR buckets are not closed immediately on reception of 4010/4012 at the message level when ccfh is configured as terminate or retry-and-terminate. Instead, some flags are set for the CDRs and when the final CDR is being released due to session termination (initiated by DCCA) the containers will be closed and casueForRecordClosing will be an abnormal release with the appropriate change condition.
In the earlier releases, when the Diameter proxy was not configured, the grouped AVP “Vendor-Specific-Application-Id” in CER/CEA messages contained all the Vendor IDs present in the dictionary file. Hence, if the Gx application used a Customer Specific AVP, this Vendor ID was also added in the Vendor-Id of Vendor-Specific-Application-Id AVP.
In the current release, if use-proxy is not configured in the Diameter endpoint, the Vendor-Specific-Application-Id AVP in CER/CEA messages will contain only the 3GPP Vendor ID (10415) in the Vendor-Id of the Vendor-Specific-Application-Id AVP.
The interchassis session recovery (ICSR) feature has been modified to support a greater number of subscribers more efficiently.
Before Release 11.0, the ASR 5000 allocated a AAA session and sub-session for every bearer. Allocating AAA sessions per bearer required great amounts of memory and CPU.
In Release 11.0 and beyond, AAA session handling has been moved from bearer level to call line level. A call-id can have a single AAA session, regardless of the number of bearers; this change allows significant savings in memory when more bearers are activated.
The AAA session handling changes resulted in subsequent changes in the way in which recovery and ICSR work. Therefore, ICSR from StarOS 10.0 or lesser versions will not work when ICSR is attempted to StarOS 11.0 and above. The following table gives a brief overview of different StarOS versions and whether ICSR is supported or not.
|
StarOS Version (Active)
|
StarOS Version (Standby)
|
|
In the earlier releases, for PGW mediation accounting, the number of digits in 3GPP-IMSI-MCC-MNC AVP was decided based on the MCC and MNC in the PGW service PLMN configuration.
In the current release, the number of digits in the 3GPP-IMSI-MCC-MNC attribute value is purely based on a hardcoded table containing a list of MCCs for which the MNC is of 3 digits.
Note that internally a table is maintained for this, which is used to compare the first three digits of IMSI with entries in the table and check whether there is a match. If yes, the MNC is encoded as three digits (which is the 4th, 5th and 6th digits in IMSI) else it will be encoded as 2 digits (4th and 5th digits of IMSI).
Multiple-Services-Indicator AVP in Diameter CC Requests - Behavioral Change
In the earlier releases, Multiple-Services-Indicator AVP was sent in all diameter CC request messages - CCR(I/U/T).
In the current release, Multiple-Services-Indicator AVP will be sent in CCR-Initial message only. This AVP will not be sent in update/terminate requests. This is applicable for all Gy dictionaries.
This Diameter-related behavioral change is applicable to all products that use the Gx interface, and all Diameter dictionaries except for the KTF-specific dictionary.
In the earlier releases, PCEF considered the Monitoring-Key AVP as an unsigned integer internally and hence stripped off the insignificant zeroes in the AVP while encoding/decoding it over Gx.
In the current release, the insignificant zeroes are not stripped off while encoding/decoding the Monitoring-Key AVP over Gx.
In 12.0 and later releases, no new attributes can be added to the starent-vsa1 dictionary. If there are any new attributes to be added, these can only be added to the starent dictionary. For more information, please contact your Cisco account representative.
Notification of Bearer Session Termination During Failover - Behavioral Change
In the earlier releases, if in a scenario where there are multiple network initiated bearers and one UE initiated bearer and if only UE initiated bearer is down,
|
l
|
the PCRF was not notified about the bearer deletion i.e., a CCR-U with bearer operation termination was not sent to the PCRF.
|
|
l
|
Also, the “show ims-authorization sessions full all” CLI command displayed one IMSA session after the deletion of UE initiated bearer.
|
|
l
|
PCRF will be intimated about this bearer deletion i.e., a CCR-U with bearer operation termination will be sent to PCRF. Subsequently, a new IMSA session will be created for one of the existing network initiated bearers (Normally IMSA session will be created ONLY for UE initiated bearers).
|
|
l
|
Before receiving the answer (CCA) from PCRF, the “show ims-authorization sessions full all” CLI command will show two IMSA sessions.
|
|
l
|
After receiving the answer (CCA) from PCRF the “show ims-authorization sessions full all” CLI command will show one IMSA session.
|
Whenever RADIUS/Diameter prepay server blacklists content the packets are generally discarded. To enable redirection of such content, post-processing on blacklisted content is required. With this change, RADIUS/Diameter Credit-Control application will decide on whether to allow post-processing to be enabled or not for the blacklisted content.
In release 12.0, in the ACS Rulebase Configuration Mode, the following configuration is available to enable post-processing priority based rules for content in blacklisted state.
Release 12.0 onwards “cca quota-state ...” and “cca redirect-indicator ...” ACS ruledef commands should be used as a post-processing rule. And, “post-processing policy always” command should be configured in the ACS Rulebase Configuration Mode for these post-processing rules to be enabled for blacklisted content.
IMPORTANT: In existing deployments, this requires changes to configurations with quota-limit rules for certain features to work.If this configuration change is not undertaken, when the content is blacklisted and for any packet that can be redirected and that matches this blacklisted content, then redirection will not happen based on “flow action redirect-url” command.
In the current release, the Diameter routing logic has been modified to enable routing to destination hosts that are not directly connected to the Diameter clients like GGSN, MME, PGW, and that does not have a route entry configured. Message routing to the host is based on the realm of the host.
For a given session towards a Destination Host, all the messages belonging to the session will be routed through the same peer until the peer is down. If the peer goes down, for the subsequent messages failure handling mechanism will be triggered and the message will be sent using other available peers connected to the destination host.
In the earlier releases, if default bearer QoS/APN AMBR change was reported in CCR-U but not authorized by PCRF, the access side Update PDP context (UPC) request was rejected with GTP_SYSTEM_FAILURE message in case of 3G call on P-GW.
In the current release, if QOS_Change trigger is hit and PCRF does not authorize the QoS, the access side UPC request is not rejected in case of 3G call on PGW.
In the earlier releases, if Revalidation-Time AVP sent in CCA-I message by PCRF fails sanity checks, call is terminated with the Termination-Cause AVP set to the value DIAMETER_BAD_ANSWER (3).
In the current release, the call will continue irrespective of the sanity failure status of Revalidation-Time AVP in the CCA-I message.
This release of StarOS incorporates the initial hooks required to support Cisco Smart Call Home (SCM). Smart Call Home is a powerful service capability of Cisco SMARTnet® Service that offers real-time alerts, remediation, and personalized web-based reports on select Cisco devices. Customers and the Technical Assistance Center (TAC) get the information they need to quickly identify and resolve network issues rapidly.
|
l
|
Providing a continuous connection to Cisco that provides monitoring, real-time troubleshooting, alerts, and remediation on select Cisco “call home” enabled devices.
|
|
l
|
Automatically generating a Cisco Service Request for severity 1 problems and is sent to the appropriate engineer at TAC.
|
|
l
|
Giving the customer greater visibility into network performances through Call Home messages, recommendations, inventory, field notices, security advisories, and End-of-Life notices for select Cisco devices through a Web-based portal.
|
Smart Call Home will be available as part of a Cisco SMARTnet Service contract. For more information, refer to the Smart Call Home website at: http://www.cisco.com/en/US/products/ps7334/serv_home.html.
In the earlier releases, if a 3GPP Rel. 7 based dictionary is already configured with diameter dictionary dpca-custom4 command, and then if the diameter update-dictionary-avps 3gpp-r9 command is applied, the Supported-Features AVP was sent with “M” bit set.
In the current release, if a 3GPP Rel. 7 based dictionary is already configured with diameter dictionary dpca-custom4 command, and then if the diameter update-dictionary-avps 3gpp-r9 command is applied, the Supported-Features AVP will be sent with “M” bit cleared. All sub AVPs in this grouped AVP will also have 'M' bit cleared.
This release supports TACACS+ authentication, authorization and accounting services for ASR 5000 administrative users.
For more information on TACACS+ configuration and maintenance, refer to the ASR 5000 Series System Administration Guide, the ASR 5000 Command Line Interface Reference, and the ASR 5000 Statistics and Counters Reference.
In the earlier releases, when the OCS Gy servers are down, then in the CCR-T request message, the Termination-Cause AVP had DIAMETER_LOGOUT as the termination cause.
In the current release, Termination-Cause AVP will have DIAMETER_ADMINISTRATIVE as the termination cause in the CCR-T.
In release 12.0, in the Policy Control Configuration mode, the following configuration is available to upgrade any 3GPP release based dictionary to higher version.
Release 12.0 onwards, if a Rel. 7 based dictionary is already configured with diameter dictionary dpca-custom4 command, and then if the diameter update-dictionary-avps 3gpp-r9 command is applied, the Supported-Features AVP with feature bit 1 being set will be sent in the CCR-I to indicate that 3GPP Rel. 9 AVPs are also supported.
|
In the CCR-I, Supported-Features AVP will be encoded with value 2 for the Feature-List AVP.
The Feature-List AVP value suggest that it is 3GPP Rel. 9 compliant. But, it is not fully complaint to 3GPP Rel. 9.
In the current release, for this upgrade scenario (3GPP Rel. 7 to 3GPP Rel. 9), only volume reporting related AVPs mentioned in the 3GPP Rel. 9 will be supported.
|
|
|
In the CCR-I, Supported-Features AVP will be encoded with value 1 for the Feature-List AVP.
The Feature-List AVP value suggest that it is 3GPP Rel. 8 compliant. But, it is not fully complaint to 3GPP Rel. 8.
In the current release, for this upgrade scenario (3GPP Rel. 7 to 3GPP Rel. 8), none of the features mentioned in 3GPP Rel. 8 will be supported.
|
|
|
In the CCR-I, value for the Feature-List AVP in the Supported-Features AVP will be 2.
The Feature-List AVP value suggest that it is 3GPP Rel. 9 compliant. But, it is not fully complaint to 3GPP Rel. 9.
Currently for this upgrade scenario (3GPP Rel. 8 to 3GPP Rel. 9), only volume reporting related AVPs mentioned in 3GPP Rel. 9 will be supported.
|
In the earlier releases, for Default-EPS-Bearer-QoS AVP, the IMSA validation for Quality of service Class Identifier (QCI) range was performed based on standard specifications. The ranges 1–9 and 128–254 were considered valid.
In the current release, the range 1–32 is valid. This change has been implemented to align with the configurable QCI range that the CLI supports.
This Diameter-related behavioral change is applicable to all products that use the STa and S6b application interfaces.
In the earlier releases, CER/CEA for STa and S6b applications included all the vendor-ids supported by the dictionary in Vendor-ID AVP under Vendor-Specific-Application-ID Grouped AVP. However, per the specification, it should include only 3GPP Vendor-ID (10415) as these are 3GPP specific applications.
In the current release, for the STa and S6b applications, the CER/CEA will have only 10415 (3GPP Vendor-ID) as Vendor-ID AVP value under Vendor-Specific-Application-ID AVP.
|
l
|
Total threshold level along with uplink/downlink threshold level is treated as an error and only total threshold level is now accepted.
|
|
l
|
Enabling and disabling session usage in a single message from PCRF is now supported. This is only if the monitoring key is associated at session level.
|
|
l
|
If no new threshold is provided in response for the usage report, monitoring is stopped. Earlier workaround to stop monitoring by providing the Usage-Monitoring-Information AVP but without threshold is now not applicable.
|
|
l
|
Monitoring usage based on input/output octet threshold levels is now supported. Usage is reported based on the enabled threshold level. If multiple levels are enabled, usage will be reported on all the enabled levels even if only one of the levels is breached. Monitoring will be stopped on the missing threshold levels in the response for the usage report from PCRF (expected to provide the complete set again if PCRF wants to continue monitoring on the multiple levels enabled earlier).
|
|
l
|
For more information on Volume Reporting over Gx feature, refer to the Gx Interface Support appendix in the administration guide for the product that you are deploying.
In the earlier releases, CCR-U with accumulated usage report was sent for immediate reporting request or explicit usage monitoring disable request by PCRF without any new threshold in CCA-U, which corresponds to the usage report in previous CCR-U for the same monitoring keys.
In the current release, the usage monitoring information instances containing Usage-Monitoring-Report / Usage-Monitoring-Support are not forwarded if the usage for the corresponding monitoring keys have been reported in CCR-U. This avoids the duplication of sending another CCR-U with zero usage when no new threshold is provided by PCRF for the corresponding usage report.
Change in Value for Termination-Cause AVP During Call Termination - Behavioral Change
In the earlier releases, on clearing the call with the clear subscribers all command, DIAMETER_LOGOUT was sent as Termination-Cause to the OCS in CCR-T.
In the current release, on clearing the call DIAMETER_ADMINISTRATIVE is sent as Termination-Cause to the OCS in CCR-T.
This Diameter-related behavioral change is applicable to GGSN, HSGW, PDG, PDIF, P-GW, SCSCF/ICSCF, S-GW.
New behavior: If there are multiple dynamic routes (multipath routes) for a host then either all should exist or none should exist. That is, a multipath dynamic route entry will be deleted only if all the multipath routes are expired. Because of this change the cli command, show diameter route table will show dynamic route entries with negative expiry value.
In the earlier releases, for 3GPP-SGSN-MCC-MNC AVP, the mandatory (M) bit was reset thereby causing Gx CCR-I to be rejected.
This behavioral change to aaa-custom5 dictionary is customer specific. For more information contact your local sales representative.
In the earlier releases, CER/CEA received without Acct-Application-Id AVP was considered as an error due to the fact that the Diameter connections were closed at that time.
In the current release, Diameter connections will remain active even when CEA is received without Acct-Application-Id AVP. Hence, CER/CEA messages received without Acct-Application-Id AVP are no longer considered as an error.
In the earlier releases, the Allocation-Retention-Priority (ARP) AVP and all sub AVPs were sent without M bit set according to 8.7.0 version of 3GPP standard spec, TS 29.212.
In the current release, the ARP AVP and all sub AVPs are being sent with M bit set as per the 3GPP standard spec TS 29.212, version 8.6.0.
New behavior: The AN-GW-Address AVP is now sent in the CCA-I and RAA messages for Gxa 3GPP2 standard dictionary.
This Diameter-related behavioral change is applicable to all products that use the Gx interface, and HSGW that use the Gxa interface.
In the earlier releases, “M” bit was set for the following Gx-specific Diameter AVPs violating the standard spec, 3GPP TS 29.212:
|
l
|
In the current release, the “M” bit is removed for these AVPs. The Diameter incoming message parsing now takes care of the absence of the “M” bit in these AVPs correctly.
Old behavior: The Packet-Filter-Content and Precedence AVPs were not sent in the update request message.
New behavior: The Packet-Filter-Content and Precedence AVPs are now sent in the CCR-U message for Gxa 3GPP2 standard dictionary.
This Diameter-related behavioral change is applicable to all products that use the 3GPP Rel. 8 Gx dictionaries “r8-gx-standard” and “dpca-custom17”.
Old behavior: The Termination-Cause AVP was not sent in the Credit-Control-Request-Termination (CCR-T) message.
New behavior: The Termination-Cause AVP is now sent in the CCR-T message for Gxa 3GPP2 standard dictionary.
Error Code Handling in Diameter for Error Code 5002 (Unknown Session ID) - Behavioral Change
This behavioral change to dcca-custom12 and dcca-custom13 dictionaries is customer specific. For more information contact your local sales representative.
When the OCS is unreachable or returns certain failure error-result codes, PCEF should assign default volume quota or time and retry the OCS server when this quota exhausts or time expires. In the earlier releases, the PCEF entered assume positive state when receiving the following error-result codes - UNABLE_TO_DELIVER (3002), UNABLE_TOO_BUSY (3004), ELECTION_LOST (4003), and Permanent failures (5000-5999).
In the current release, if the PCEF receives the result code 5002, it will disconnect the session and will not enter/re-enter assume positive state. The PCEF will initiate a new session with a CCR-I. No interim data will be reported at this point; the session will continue as a standard new Gy session.
This feature enables configuring both IMSI-based and MSISDN-based values under a particular credit control group. With this feature enabled, you can select appropriate Diameter peer based on the configured Mobile Station International Subscriber Directory Number (MSISDN) prefix/suffix/range value. Default peer will be selected when the MSISDN value does not match any of the configured range. If the default peer is not configured, one of the peers in Diameter endpoints will be chosen.
Output of Session Active Counter in show ims-authorization servers ims-auth-service Command - Behavioral Change
In the earlier releases, the counter “Sessions Active” under the “show ims-authorization servers ims-auth-service <service_name>” CLI command was used to indicate the total number of sessions that were referencing the server as active.
In the current release, this counter provides the count of sessions that are referencing this server as either active or standby.
In 12.2 and later releases, the RAT-Type is marked as NOT Mandatory in order to be compliant with the standard spec 3GPP TS 29.212 v8.6.0. That is, the M flag for the RAT-Type has changed from 1 to 0 in Gx CCR message.
In the earlier releases, DCCA was assuming that static rules defined in a rulebase were applicable for all bearers.
The following changes have been made in the DCCA routines to check if DCCA needs to be enabled for a session:
|
l
|
Default bearers — Check for Credit Control configuration in all static rules in the rulebase. Also check if Credit Control requirements of all predefined and dynamic rules have been installed.
|
|
l
|
Dedicated bearers — Check for Credit Control requirements of all predefined and dynamic rules have been installed. The charging-actions of the installed predefined and dynamic rules decide whether DCCA needs to be enabled.
|
In this release, the following new thresholds can be configured for generating alarms or alerts based on the archival queue percentage of AAA accounting messages.
In the earlier releases, IP CAN session was terminated on receiving an experimental result code of range 5xxx in CCA-Update request message.
In the current release, when experimental-result-code of range 5xxx is received, the Diameter peer is notified of the failure and the IP CAN session is no longer terminated.
In the earlier releases, the session level and rule level usage was reported over the Gx interface only when the volume/time threshold is breached.
In the current release, even if the volume/time threshold is reached, the session level usage is reported over Gx.
This section provides information on new Application Detection and Control (ADC) features in Release 12.0.
|
l
|
|
l
|
|
l
|
|
l
|
|
l
|
|
l
|
|
l
|
|
l
|
This section provides information on new Application Detection and Control (ADC) features in Release 12.2.
|
l
|
|
l
|
|
l
|
|
l
|
|
l
|
|
l
|
|
l
|
|
l
|
|
l
|
|
l
|
|
l
|
|
l
|
WiMAX HA and ASN-GW have been enhanced to support profile-based hotlining as per WiMAX Forum™ Network Architecture, NGW 1.5 specification. See Interface Changes for additional information.
802.1p marking is now supported on ASN-GW with or without Ethernet CS support. See Interface Changes for additional information.
Support has been added for IP 5-tuple flow-based prepaid accounting using ECSv2 rulebase configuration support for WiMAX, ASN-GW and HA calls.
Also added Hotlining support for IP 5-tuple flow-based prepaid call sand postpaid sessions on WiMAX, HA and ASN-GW.
ASN-GW now supports a single DCCA session for all the bearers in an IP-CAN Session. See Interface Changes for additional information.
Added and modified CLI commands to support PHS for WiMax Calls. See Interface Changes for details.
Added and modified CLI commands to support PHS for WiMax Calls. See Interface Changes for details.Feature
fa-ha-spi remote-address <ip_address> spi-number <spinumber> secret <secret > [allow-fa-ha-auth-extension | disallow-fa-ha-auth-extension]
A new, HA-specific dictionary has been added as “custom53”. This dictionary contains a specific set of UQ Communications (UQC) AAA attributes.
The ASN-GW can now send the RADIUS test frame (Auth Req and Acct Req) with the exact attribute set identified for the UQC dictionary.
|
l
|
IP 5-tuple [Source IP, Destination IP, Source Port, Destination Port, Protocol] flow-based prepaid accounting using ECSv2 rulebase configuration for WiMAX ASN-GW and HA calls.
|
|
l
|
Hotlining support for postpaid sessions on WiMAX HA and ASN-GW. A session can be hotlined either at the beginning or middle of the session.
|
|
l
|
Idle Mode Entry – If asn-policy idle-mode is enabled, then Interim-Update will be sent with the BSID and WiMAX-Idle-Mode-Transition as “Idle”.
|
|
l
|
Idle Mode Exit – If asn-policy idle-mode is enabled, then Interim-Update will be sent with the BSID and WiMAX-Idle-Mode-Transition as “Not Idle”.
|
|
l
|
Location Update – If asn-policy notification-handoff is enabled, the Interim-Update will be sent with the BSID and SN-Handoff-Indicator as “Location-Update”.
|
|
l
|
Handoff –If asn-policy notification-handoff is enabled, the Interim-Update will be sent with the BSID and SN-Handoff-Indicator as “Active-Handoff”.
|
|
l
|
Interim when the call is Idle – During the Idle-Mode Entry, the Interim will not be sent until the Idle-Mode Exit or Location Update.
|
In 12.0 and earlier releases, if multiple Charging-Rule-Base-Name AVP are received from the PCRF, the "last" rulebase is selected and applied to the call. In early 12.2 releases, the "first" rulebase was being selected.
To maintain a uniform behavior, in later 12.2 releases also the "last" rulebase will be selected by default.
In cases where the "first" rulebase has to be selected, in the policy-control charging-rule-base-name CLI command a new command option has been introduced to enable that. For more information, in the Configuration Management chapter see the policy-control charging-rule-base-name CLI command.
In 12.1 and earlier releases, and in early 12.2 releases, in the CLI the maximum configurable value for content-id and service-identifier was 65535 (maximum 16 bit value). Now the maximum configurable value is 2147483647 (maximum 31 bit value).
content-id 1..2147483647
service-identifier 1..2147483647
if-protocol http content-id 1..2147483647
if-protocol wsp-connection-less content-id 1..2147483647
if-protocol wsp-connection-oriented content-id 1..2147483647
cca quota time-duration algorithm continuous-time-periods 1..4294967295 [ content-id 1..2147483647 ]
The DNS Snooping feature enables a set of IP rules to be installed based on the response from a DNS query. The rule in this case contains a fully qualified domain name (for example, m.google.com) or its segment (for example, google) and a switch that causes the domain to be resolved to a set of IP addresses. The rules installed are thus IP rules. Any actions specified in the domain rule are inherited by the resulting IP rules.
Each SessMgr has some memory dimensioned based on system requirements. ECS has an internal threshold at ~90% of this memory after which it bumps up effective call credits to maximum and this causes silent rejects.
|
l
|
Silent rejects are done even if there is system memory available. Silent in the sense not known unless someone is watching the logs (e.g. no alarms).
|
|
l
|
It delays the system to recover from memory leaks by capping the calls. Without ECS, SessMgrs would eventually go to WARN, raise alarms. They can then bloat as much as there is available system memory.
|
In earlier releases, at approximately 90% CPU utilization, SessMgrs would start rejecting calls with SessMgr event ID 10018.
In this release, this limit is bumped up to ~1.25X. Note that the normal behavior is that SessMgrs reject calls at 120%, independent of ECS. SessMgrs will be able to go up to and over their dimensioned maximum capacity independent of ECS.
The Tethering Detection feature enables detection of subscriber data traffic originating from PC devices tethered to mobile smartphones, and also provides effective reporting to enable service providers take business decisions on how to manage such usage and to bill subscribers accordingly.
This release provides support for IPv6 and ICMPv6 Firewall. IPv6 Firewall supports the following features:
|
l
|
Enabling/Disabling IPv6 Firewall: The configuration can be used to enable or disable IPv6 Firewall for subscribers. IPv4 and IPv6 Firewall can be enabled or disabled separately.
|
|
l
|
IPv6 Header checks: Firewall performs the following header checks to ensure the integrity of an IPv6 packet. IPv6 packets with unknown extension headers will not be dropped by Firewall; such packets will be allowed by Firewall.
|
|
l
|
Hop-by-hop Options filtering: The Hop-by-Hop options will be parsed only if any of the Hop-by-Hop dos protections is enabled.
|
|
l
|
IPv6 Rule-match: Stateful Firewall access ruledefs are enhanced to support IPv6 addresses and other parameters like IP version and ICMPv6 protocol.
|
|
l
|
IPv6 Recovery: Stateful Firewall supports IPv6 flow recovery similar to IPv4 flows with the existing flow-recovery CLI being applicable to IPv6 flows also.
|
For more information, please refer the Personal Stateful Firewall Administration Guide and CLI Reference Guide.
GGSN controls the assignment of different radio interface QoS priorities (gold/silver/bronze) via the PCRF Gx interface during PDP context setup (CCR/CCA-I). This is performed using the Allocation Retention Priority (ARP) parameter (AVP code 1034) as specified in 3GPP TS 29.212, with values = 0-3; ARP values from the PCRF other than 0-3 are ignored. During PDP context setup the PCRF returns the ARP value in CCA-I and this ARP is then assigned/negotiated with the SGSN and RNC.
The maximum length of the charging rulebase name in List of Service Data Volumes (LOSDV) of eGCDRs can be trimmed now with the inclusion of a new command “gtpp egcdr charging-rulebase-name-max-char-length”. With this new command, user will have flexibility to decide the length of charging rulebase name. The user need to specify the rulebase name length explicitly between 1 to 63 in LOSDV to use this feature. In case zero is specified, the charging rulebase name would not be trimmed.
For more information, refer the Context Configuration Mode Commands chapter of the Command LIne Interface Reference Guide.
S6b is an optional Diameter protocol-based interface over which the GGSN communicates with 3G AAA/HSS in LTE/SAE network for subscriber authorization.
S6b interface has ability to pull SGSN-MCC-MNC from either GTP or AAA-I and send to OCS. When customer roams into GSM environment, OCS needs location information for online charging and metering. 3GPP-SGSN-MCC-MNC AVP and Location Information AVP are defined in Gy and can be used to identify customer location. With this feature, the GGSN collects the value of SGSN-MCC-MNC from the S6b AAA message, so that it can be available to OCS through Gy interface while passing CCR and CCA messages.
From Release 12.2 onwards, the S6b interface has been enhanced to pass on the UE assigned IPv6 address (IPv6 prefix and IPv6 interface ID) to the AAA server. S6b interface also has support for Framed-IPv6-Pool, Framed IP Pool, and served party IP address AVPs based IP allocation. With this support, based on the Pool name and APN name received from AAA server, the selection of a particular IP pool from the configuration is made for assigning the IP address.
Session credits and session license were counted for both primary and secondary PDP contexts of GGSN call.
CLI command added to enable/disable addition of the sequence number to every GTP-U packet coming from Gi interface and going towards Gn/Gp interface. If GTP-U packets are received out of sequence, sequence numbers would allow the packets to be reorded.
GGSN now supports IPv4v6 type PDP from release 12.2 onwards. With this support, on single PDP context, both IPv4 and IPv6 user plane can run simultaneously according to 3GPP TS 23.060 V9.8.0 specification.
TCP Proxy support is now available for Lawful Intercept on the GGSN. Contact your local Cisco sales representative for additional information.
The GGSN supports the sending of a notification to LI administrators when an existing LI target provision has been modified or deleted. Contact your local Cisco sales representative for additional information.
Rf interface enables offline accounting functions on the GGSN in accordance with the 3GPP Release 8 specifications. The charging data information is recorded at the GGSN for each mobile subscriber UE pertaining to the radio network usage. Due to the transfer of charging information to GGSN, the services being rendered are not affected in real time.
The offline charging functionality is based on the network elements that report the accounting information via different type of messages which trigger the charging generation. Following diameter accounting requests are sent from the network elements to the charging data function (CDF) to achieve this reporting:
|
l
|
|
l
|
|
l
|
|
l
|
This section provides information on new features supported on HNB-Gateway (HNB-GW) in Release 12.1.
In this release multiple MSC selection without Iu-Flex functionality for HNB-GW service is supported.
HNBGW can connect to multiple MSC and SGSN through Iu-Flex or LAC mapping. This feature implements the multiple MSC selection using LAC.
For this support the HNB-GW uses HNBs LAC, received during registration procedure in HNB_REGISTER_REQUEST message, to distribute RANAP-Initial UE message to an MSC. It maps the LAC with MSC point code and a set of LACs configured for each MSC, connected to the HNB-GW.
This section provides information on new features that pertain to the HRPD Serving Gateway (HSGW) supporting eHRPD network services in Release 12.2. Additional information on these features can be found in the Cisco ASR 5000 HRPD Serving Gateway Administration Guide and the Cisco ASR 5000 Series Command Line Interface Reference.
AN-GW-Address AVP Missed in CCR-I for Dictionary gxa-3gpp2-standard
AVPs Missed Under Packet-Filter-Information Group AVP in CCR-U for gxa-3gpp2-standard
CLI command added to enable/disable addition of the sequence number to every GTP-U packet coming from Gi interface and going towards Gn/Gp interface. If GTP-U packets are received out of sequence, sequence numbers would allow the packets to be reorded.
Default EPS Bearer QoS was not supported in Gxa messages in earlier releases. Support has been added in CCR/CCA/RAR messages.
In case of Default EPS Bearer QoS, the value received from STA in EPS_SUBSCRIBED_QOS_PROFILE will be passed on in CCR-I to PCRF.
PCRF is supposed to respond in CCA/RAR with QCI 9 for Default Bearer. If HSGW receives a value other than 9, a log is printed. HSGW does not terminate the call in such cases.
Event-Trigger related AVPs were not included in RAA when RAR with Event Trigger was received. Support has been added in RAA messages.
|
l
|
RAR with event trigger not set ->Include the current applicable values if the value has changed. Do not include the AVP, if the value has not changed.
|
Flow-Information AVP was not supported inside QoS-Rule-Definition in Gxa messages. Support has been added in CCA/RAR messages.
Event trigger Resource Modification Request will be triggered when a Resource Modification Request is triggered from UE. Earlier event triggers QoS Change/TFT Change were used for the same.
The event trigger Resource Modification Request need not be turned on from PCRF; it is enabled by default.
Session-Linking-Indicator was not supported in Gxa messages in earlier releases. Support has been added in CCR messages.
|
l
|
CCR-I sent as a result of PDN Connect will have the value SESSION_LINKING_DEFERRED.
|
|
l
|
CCR-I sent as a result of BBERF Relocation will have the value SESSION_LINKING_IMMEDIATE
|
Supported-Features AVP was not supported in Gxa messages in earlier releases. Support has been added in CCR/CCA messages.
HSGW shall set the Supported-Features AVP to Release 9 to indicate compliance to Rel 9. HSGW does not terminate the session if PCRF advertises release 8 support.
In case of Gx, these parameters are sent as part of the filters to UE and are used for rule matching. Packet Filter ID needs to be stored for all rules which are configured by PCRF as a result of UE-requested resource modification process. These filter IDs need to be used as a key between PCRF and BBERF for any further modification of the SDF/QoS. Refer to 3GPP TS 29.212: Policy and Charging Control over Gx reference point, for more details.
This scenario occurs when the PDN-specific AMBR is modified by the AAA and the PCRF has subscribed for the QOS_CHANGE Event Trigger. The HSGW shall send a CCR-Update with QoS-Information (UPDATE) for the PDN to update the AMBR information provided for the APN.
HSGW supports enabling of pre-defined rules/rulebase from PCRF for Gxa interface. SM supports enabling the rules received from PCRF.
|
1
|
The pre-provisioned policy (policy-map, policy-group) needs to be configured in HSGW configuration. Based on the request in diameter messages (CCA, RAR) for inclusion or removal of a given policy-group/rulebase or policy-map/rulename, the rules are loaded and take effect for data tx/rx and QoS Check process.
|
|
2
|
The assumption here is that if HSGW receives a policy-group/rulebase name in diameter msg to load the rules, HSGW will be loading all of the policies within the given policy-group other than type template. If a policy is termed as type “template,” it will only be loaded if HSGW gets the rulename/policy-map in the diameter msg request.
|
|
3
|
Once the rules are loaded based on above request, it will be effective for rule matching for data transfer and QoS Check/TFT-matching process.
|
If a bearer is terminated on the HSGW, the HSGW will generate a CCR-U with a charging rule report containing the list of rules affected by the event and a rule status of inactive.
Each Packet-Filter-Information AVP shall include a packet filter identifier as provided by the PCRF in the QoS rule within the Packet-Filter-Identifier AVP identifying the previously requested packet filter being modified and, if the precedence value is changed, shall include packet filter precedence information within the Precedence AVP.
The Packet-Filter-Identifier AVP (AVP code 1060) is of type Octet String, and it indicates the identity of the packet filter. The packet filter identifier is assigned by the PCRF and within the scope of the PCRF is unique per UE.
Host names are expected to be configured with either “topon” or “topoff” as the first label in the DNS server. In absence of “topxx” label, host name should be treated as implicit “topoff” and first label of DNS returned host name should be stripped to yield the node name for use in topology match.
When P-GW host name does not have topxx label, APN and P-GW FQDN discovery are performed correctly by HSGW.
CLI added to subscriber template to enable the time interval in milliseconds to wait for router solicit before sending the initial IPv6 router advertisement.
If mag-service has “mobility-option-type custom2” configured, MAG will send APN-NI+OI in Service Selection field in PBU. APN-OI is constructed from IMSI in EAP NAI and will have the following format:
The HSGW will support P-GW lookup for initial attach using the APN. If the MIP6-Agent-Info header is not present, or empty, then the APN FQDN will be used, which has the format of:
During dynamic P-GW node selection by MME and HSGW, if the selected P-GW is unreachable, MME and HSGW select the next P-GW entry from the P-GW candidate list returned during the S-NAPTR procedure to set up the PDN connection.
When eHRPD PDN comes up, PMIPv6 session is tried with first P-GW selected and if no reply is received for max-retransmission...
If P-GW does not respond, HSGW tries with another P-GW if available based on DNS resolution results by starting with initial retransmission timeout as configured. There is no limit on the number of P-GW fallback attempts per PDN and HSGW will keep trying fallback as long as alternate P-GWs are available. The session may, however, get dropped if session-timeout gets triggered, in which case PMIPv6 PDN will also get deleted.
The Cisco Lawful Intercept feature is supported on the HSGW. Lawful Intercept is a licensed enabled, standards-based feature that provides telecommunications service providers with a mechanism to assist law enforcement agencies in monitoring suspicious individuals for potential illegal activity. For additional information and documentation on the Lawful Intercept feature, contact your local Cisco sales representative.
Maximum Number of eHRPD PDNs Supported Per Session Configurable
Previously, the maximum number of eHRPD PDNs supported per subscriber session had a hard limit of three.
Now, the maximum number of eHRPD PDNs supported per session is configurable from 1 to 14. Default is 3.
The Network Initiated QoS control is a set of signaling procedures for managing bearers and controlling their QoS assigned by the network. This gives network operators full control over the QoS provided for its offered services for each of its subscriber groups.
If the UE supports Network Initiated QoS, then the UE shall include the MS Support of Network Requested Bearer Control indicator (BCM) parameter in the additional parameter list of the PCO option when sent in the vendor specific network control protocol (VSNCP) Configure-Request from the UE to the HSGW. Otherwise, the UE shall not include the MS Support of Network Requested Bearer Control indicator (BCM) parameter.
Now, when PMIP P-GW receives a PBU with Handoff Indicator set to 2 or 4 (indicating inter-tech handoff) and matching session for IMSI/APN is not found in either eHRPD or LTE, then PBU will be rejected with status code 159 BCE_PBU_PREFIX_SET_DO_NOT_MATCH.
Node Selection: P-GW IP Address Updated and Retrieved During Handover Description
If PGW-ID (either IP address or PGW-FQDN) is received in MIP6-Home-Agent-Info AVP on the STa interface, it is only used if one of the following conditions is met:
The HSGW currently supports the following Release 9 3GPP specifications. Most 3GPP specifications are also used for 3GPP2 support.
|
l
|
3GPP TS 21.905: Vocabulary for 3GPP Specifications
|
|
l
|
3GPP TS 23.401: General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access
|
|
l
|
3GPP TS 23.402. Architecture enhancements for non-3GPP accesses
|
|
l
|
3GPP TS 29.212: Policy and Charging Control over Gx reference point
|
|
l
|
3GPP TS 29.214: Policy and Charging control over Rx reference point
|
|
l
|
3GPP TS 29.229: Cx and Dx interfaces based on Diameter protocol
|
|
l
|
3GPP TS 29.273: 3GPP EPS AAA Interfaces
|
Support for Storing EPS_SUBSCRIBED_QOS_PROFILE Received from STa in sessmgr
If Default-Bearer-QoS is received over STa, the value is included in CCR-I. Any change of Default_Bearer_QoS via the Reauth procedure is included in the subsequent CCR-U.
The NAI sent in the Mobile Node Identifier field in PMIPv6 will not include the digit prepended in front of the IMSI that is described above.
The current HSGW includes NAI received in EAP, and P-GW also expects this digit to be present. To support removing the leading digit, mobility-option-type-value standard configuration in MAG/LMA service will be used to support S2a MN-ID. There is no behavior change for custom1 and it will continue to work as usual.
Completed P-GW changes to extract IMSI from NAI and handle cases when auth-mode digit is included or removed. mobility-option-type configuration is used and standard is expected to receive PBU without digit prepended.
In both HSGW/P-GW, PBU is expected to have <IMSI>@realm where IMSI field can only be maximum of 16 digits, including auth-mode. If it is more than 16 digits, then it is decoded as invalid IMSI format and IMSI will not be extracted.
In addition, mobility-option-type custom2 configuration has been added for this feature. The standard will continue to work as before.
Termination-Cause AVP Missed in CCR-T Dictionary gxa-3gpp2-standard
This section provides information on new InTracer features in release 12.2. For more information on InTracer, refer InTracer Installation and Administration Guide.
InTracer now supports configuration of 7600 for subscriber and equipment trace, which involves setting trace parameters like trace profile, transfer interval, buffer limit, access to NE, enabling/ disabling trace and viewing trace status and statistics.
Architectural change is an enhancement of existing TCE application to support the high scalability and to support high load from gateway.
This section provides information on new IP Services Gateway (IPSG) features in Release 12.0. For more information on IPSG, refer the IP Services Gateway Administration Guide.
Cell re-selection from a 3G SGSN to an MME based on receiving an S1AP Init UE-based TAU request is now supported.
The S3 interface facilitates user mobility between an MME and a Release 8 SGSN providing for the transfer of the UE context between the MME and the SGSN.
Circuit Switched Fall Back enables a UE to camp on an E-UTRAN cell and originate or terminate voice calls through a forced switchover to the CS domain.
The MME now supports timeout and failure handling for the EIR on the S13 interface. Configuration of the timeout and/or failure response is now available. Refer to the attach and tau commands in the “Mobility Management Entity Command - Modified in Release 12.0” in the Configuration Management chapter for more information.
IP Security (IPSec) on the S1-MME interface is a node-to-node IKEv2 tunnel that can be configured to assume the characteristics of either a pre-configured tunnel or a dynamic tunnel.
Pre-configured node tunnels are fully qualified IPSec tunnels. Each IPSec tunnel is configured with parameters including pre-shared key, local and remote IP addresses, crypto hashes, groups, algorithms and the access control list (ACL).
Node-to-node dynamic tunnels are generated dynamically as the connections are initiated by different nodes in the LTE network. Each IPSec tunnel does not need to be pre-configured for each required parameter, instead it uses a common template for some parameters, like crypto algorithms, hashes, and groups. Other parameters are fetched dynamically from the tunnel requests like IP addresses and traffic selectors. Authentication information is fetched dynamically via certificates.
Typically, the eNodeB initiates an IPSec tunnel to the MME. The MME service is responsible to verify the configuration and use an IPSec API to make the MME listen on the service address for IKE requests.
The S1-MME Interface carries SCTP signaling traffic that flows through an IPSec tunnel if it is configured. When a UE needs to connect to the Internet, it initiates a connection to an eNodeB which then tunnels its traffic to an MME using an SCTP connection. Any further UEs using the same eNodeB to communicate to the same MME will subsequently use the same SCTP and hence the same IPSec Tunnel according to the LTE standard.
The MME supports X.509 certificate-based peer authentication for IPSec tunnels over the S1-MME interface.
The MME service supports up to four SCTP bind end point IPv4 or IPv6 addresses for the S6a interface.
The MME now supports behavior that allows the peer realm of the HSS to be determined by the MCC and MNC in the subscriber’s IMSI. Prior behavior was that the HSS must be statically configured in the MME.
Error Message Correction for Maximum Peer SGSN RNC/RAI Configurations
The MME now correctly identifies error conditions related to reaching the maximum number of configured peer SGSN RNCs and RAIs.
When the maximum number of peer-SGSN RAI entries were exceeded (32), the error message displayed was: Failure: Unable to retrieve information: error 390:0
When the maximum number of peer-SGSN RNC-ID entries were exceeded (32), the error message displayed was: Failure: Unable to retrieve information: error 390:0
When the maximum number of peer-SGSN RAI entries are exceeded (32), the new error message displayed is: Failure: Maximum number of Peer SGSN RAI entries already configured
When the maximum number of peer-SGSN RNC-ID entries are exceeded (32), the new error message displayed is: Failure: Maximum number of Peer SGSN RNC-ID entries already configured
NAS messages received in an incorrect order were piggybacked without re-ordering and retried causing error conditions.
If NAS messages require re-ordering, piggybacking is not performed. For example, for a piggybacked Create Bearer Request, if there is a re-order of the NAS/S1AP message, then the Create Bearer Response message will not be piggybacked with the Modify Bearer Request message.
The MME now has the ability to configure the network resource identifier (NRI) length used for source SGSN discovery via NRI-FQDN based DNS resolution. MME now uses the NRI field to resolve peer SGSN during TAU handoffs and Attaches with mapped GUTI. The length of the NRI field can now be configured for a given PLMN. This allows the MME to extract NRI unambiguously from P-TMSI. For more information, refer to the nri command in the Mobility Management Entity Commands - New in Release 12.2 section of the Configuration Management chapter of this change reference.
The MME now also supports using NRI-based FQDN to resolve the source SGSN. More specific DNS entries can be configured corresponding to each SGSN. SGSNs are now not required to support relay functionality in order for SGSN Context Request and Identification Request messages to reach source SGSN.
The MME now supports a maintenance command enabling an operator to enable or disable 'offload' mode for a specified VLR. This capability enables operators to preemptively move subscribers away from an SGs interface associated with an MSS which is planned for maintenance mode.
When this offload command is set on the MME, all sessions matching this VLR are marked with an ‘offload’ flag. During the next UE activity, the MME requires each UE to perform a combined TAU/LAU.
The VLR offload functionality and MME offload functionality can be used in a mutually exclusive fashion, such that activation of one prevents activation of the other (and vice versa).
Refer to the sgs offload sgs-service command in the Mobility Management Entity Command - New in Release 12.2 section in the Configuration Management chapter for more information.
Modify Bearer Requests always included the APN-Aggregate Maximum Bit Rate (AMBR) information element.
During a Default Bearer Context activation procedure, the MME sent an ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message but did not include the operator identifier (mnc <mnc>.mcc<mcc>.gprs) in the Access Point Name information element.
The APN information element now includes both the operator identifier and network identifier in ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST messages.
To support a network sharing configuration where core network elements (MME, SGW, PGW) are shared between different service providers, the MME service can now be configured with multiple local PLMNs per service. Each mme-service is now able to process multiple PLMNs and indicate this to the eNodeb during S1 SETUP procedures.
The configuration of these additional PLMNs is implemented using the network-sharing command within the mme-service config mode.
Refer to the MME Commands - New in Release 12.2 section in the Configuration Management chapter of this guide and to the Cisco ASR 5000 Series Command Line Interface Reference for details of this new CLI command.
During a 2G to 4G Tracking Area Update (TAU), the MME sent the SGSN a Context Request message. If the SGSN replies with an SGSN Context Response which includes no PDP contexts, the MME then sent back a Context Acknowledge message with a GTP_MANDATORY_IE_MISSING error, and the TAU would fail.
In this case, the MME assumed that the UE would never perform a TAU Attach with zero PDP Contexts active in 3G. As a result, the SGSN Context Response with missing PDP contexts was treated as an error condition.
If the SGSN Context Response is received with no PDP contexts, the MME now responds with an SGSN Context Acknowledge with cause 'Request Accepted' allowing the Gn/Gp context transfer, but then rejects the TAU with cause 'No EPS bearer context activated'.
The MME included the preamble in the target-id of relocation requests (sender side) and always expected the preamble in the target-id of relocation request (receiver side).
By default (on sender side), the MME no longer includes the preamble in the target-id of relocation requests. On receiver side, the SGSN/MME will act per target-id length. If the target-id length is 8, then the SGSN/MME will act as target-id without preamble.
To enable the old behavior, refer to the gtpc command in the Mobility Management Entity Commands - Modified in Release 12.2 section of the Configuration Management chapter of this change reference.
The MME now has the ability to configure the network resource identifier (NRI) length used for source SGSN discovery via NRI-FQDN based DNS resolution. MME now uses the NRI field to resolve peer SGSN during TAU handoffs and Attaches with mapped GUTI. The length of the NRI field can now be configured for a given PLMN. This allows the MME to extract NRI unambiguously from P-TMSI. For more information, refer to the nri command in the Mobility Management Entity Commands - New in Release 12.2 section of the Configuration Management chapter of this change reference.
The MME now also supports using NRI-based FQDN to resolve the source SGSN. More specific DNS entries can be configured corresponding to each SGSN. SGSNs are now not required to support relay functionality in order for SGSN Context Request and Identification Request messages to reach source SGSN.
Regional Zone Code Restriction allows an operator to control the areas in which a UE can roam in to receive service. The code representing the zone in which a UE is to be offered service by the network can be configured in the HSS or using local provisioning in the MME.
|
l
|
3GPP TS 24.301 V9.5.0 (2010-12): 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS); Stage 3 (Release 9)
|
|
l
|
3GPP TS 29.274 V9.5.0 (2010-12): 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 3GPP Evolved Packet System (EPS); Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for Control plane (GTPv2-C); Stage 3 (Release 9)
|
|
l
|
3GPP TS 29.272 V9.5.0 (2010-12): 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 3GPP Evolved Packet System (EPS); Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) related interfaces based on Diameter protocol (Release 9)
|
|
l
|
3GPP TS 36.413 V9.5.0 (2010-12): 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 Application Protocol (S1AP) (Release 9)
|
The MME now supports the suspend notification on the S3 interface from the SGSN per 3GPP TS 23.272 (9.5.0) and TS 29.274 (9.4.0). The suspend notification is received and responded to by the eGTP-C demux process.
The SGs interface between the MME and the MSC/VLR now supports SCTP multi-homing. Refer to the bind and vlr commands in the “Mobility Management Entity Commands - Modified in Release 12.2” section of the Configuration Management chapter for more information.
The MME Demux task now learns about SGs services, and configured VLRs, and assigns them to MME Managers based upon a hash algorithm.
CSFB mobile emergency calls now use the emergency cause code to indicate to the eNodeB that the call is for emergency purposes. The CS-Fallback-High-Priority cause code is supported in Release 9.
Per section 5.1.3.1 of 3GPP TS 29.118, the MME now supports IMSI paging based on the following from the specification:
If the UE is not known and the “MME-Reset” restoration indicator at the MME is set to “true”, the MME shall handle the paging request as follows:
|
l
|
if the MME only supports “SMS only”, the MME shall return an SGsAP-PAGING-REJECT message to the VLR indicating in the SGs cause information element “Mobile terminating CS fallback call rejected by the user”;
|
|
l
|
if the SGsAP-PAGING-REQUEST message includes the Location area identifier information element, the MME shall page the UE in all the tracking areas served by the MME that can be mapped to the location area indicated in the Location area identifier information element; or
|
|
l
|
if the SGsAP-PAGING-REQUEST message does not include the Location area identifier information element, the MME may page in all the tracking areas served by the MME, or the tracking areas served by the MME and by the VLR.
|
NOTE: The MME can initiate the paging procedure using IMSI with CN domain indicator set to “PS” to request the UE to initiate the attach procedure as described in 3GPP TS 24.301.
Support for Dual Addressing on Pre-release 8 SGSNs (Gn/Gp) - Behavioral Change
The MME now supports dual-addressing for all network nodes including pre-release 8 SGSNs over Gn/Gp.
Support for Dual Addressing on Pre-release 8 SGSNs (Gn/Gp) - Behavioral Change
The MME now supports dual-addressing for all network nodes including pre-release 8 SGSNs over Gn/Gp.
The MME now supports timeout and failure handling for the EIR on the S13 interface. Configuration of the timeout and/or failure response is now available. Refer to the attach and tau commands in the “Mobility Management Entity Command - Modified in Release 12.2” in the Configuration Management chapter for more information.
The MME supports RAN Information Management (RIM) procedures as defined in 3GPP TS 23.401 on the S1-MME, S3, Gn, and S10 interfaces.
S1AP and RANAP cause codes are mapped as directed in 3GPP TS 23.401 (V9.7.0) and TS 29.010 (V9.2.0).
MME Support for (RIM) Information Exchange Between eNodeB and RNC - Behavioral Change
The MME now supports the transparent exchange of RIM information that helps target an RNC to establish RRC connection with the UE.
Support for eNB/MME (S1-MME) Direct Information Transfer Procedure - Behavioral Change
The eNB/MME Direct Information Transfer procedure transfers RAN information between an eNB and an MME in unacknowledged mode. The MME does not interpret the transferred RAN information. This procedure uses non-UE associated signalling.
The eNB/MME Configuration Transfer procedure transfers RAN configuration information between the eNB and the MME in unacknowledged mode. The MME does not interpret the transferred RAN configuration information.
The MME now supports SON information transfer via MME/eNB Configuration Transfer messages defined in 3GPP TS 36.413.
The MME now supports the initiation of IPSec tunnels to the eNodeB if the following conditions exist:
|
l
|
The first tunnel setup is always triggered by eNodeB. This is the tunnel over which initial SCTP exchanges occur.
|
|
l
|
the eNodeB is multi-homed: Tunnels are initiated from MME's primary address to each secondary address of eNodeB.
|
In all three cases, the MME does not initiate a duplicate tunnel between the same end points if such a tunnel already exists, either because the eNodeB initiated them previously or because the tunnels from a previous initiation by the MME were not torn down.
If there is collision, for example, if the eNodeB also initiates a tunnel in the meantime, the tunnel initiated by eNodeB is given preference and the MME-initiated tunnel is torn down. This can happen both after an MME-initiated tunnel has been established or is waiting establishment.
Tunnels initiated by the MME are not torn down when the SCTP associations on the tunnels no longer exist.
IP versions over S11/S10/S3 are not dependant on each other. For example, the MME may use IPv6 over S11 and IPv4 over S10 (provided the MME-EGTPC-Service is bound to both IPv6 and IPv4 address).
The logic for selecting an S-GW/peer-MME/peer-SGSN is now: preference is given for IPv6 addresses. IPv4 addresses are ignored if IPv6 addresses are present. This applies to weighted selections using the TAI database, as well. Weights for IPv4 addresses are ignored if IPv6 addresses are present (only IPv6 addresses are load-balanced if present).
If the MME-EGTPC-Service is bound to an IPv4 address and there are only IPv6 addresses available during peer node selection (and vice versa), it is considered as a node selection failure (reason: No suitable addresses available).
TCP Proxy support is now available for Lawful Intercept on the MME. Contact your local sales representative for detailed information.
The MME now supports the ability to send notifications to LI administrators when an existing LI target provision has been modified or deleted. CP Proxy support is now available for Lawful Intercept on the MME. Contact your local sales representative for detailed information.
The MME now supports RAU-based attach procedures to a 2G SGSN over the S3 interface as defined in 3GPP TS 23.401.
This feature applies to additional PDN connection for an APN that already has an existing PDN connection, all within a UE context. In such situations, the additional PDN connection uses the same P-GW as the existing connection if both the following conditions are met:
DNS discovery will still happen for the new PDN request as the fallback list is built up front using the existing design. This avoids changes to NAS FSM. But the requests will be fed from local cache and external requests will be rare unless the TTL is very low.
2011-Feb-22+16:10:02.742 [mme-app 147003 info] [1/0/21528 <sessmgr:1> mme_app_util.c:10826] [callid 00004e29] [context: ingress, contextID: 2] [software internal system syslog] Existing PGW for same APN re-used.
The P-GW re-use does not apply if the P-GW for the existing connection was allocated statically by any of the following means:
Support for Out-of-order Reception of Default and Dedicated Bearer UE Responses - Behavioral Change
The MME now does not retry the dedicated bearer request even if the dedicated bearer response is received before the default bearer response, once a successful default bearer response is received.
If the message could not be delivered due to an intra-MME handover and the target TA is included in the TAI list, then upon successful completion of the intra-MME handover the MME retransmits the message. If a failure of the handover procedure is reported by the lower layer and the S1 signalling connection exists, the MME retransmits the message.
|
l
|
Deactivate Bearer Request - Supported, but not resumed after HO, since during HO the relevant PDN or bearer is deleted
|
Monitor protocol supports decoding of S1AP NAS Non-delivery indication message. The NAS protocol selector shall not show these message since these are not messages sent by UE
S1AP statistics count the NAS Non-delivery indication message. The un-delivered messages are not counted against NAS statistics.
UMTS networks are configured with LACs allocated from the reserved space of 32K to 64K. In LTE networks, this space is typically reserved for MME group IDs. To overcome this issue during inter-RAT handovers, the MME can now be configured with mappings between LACs and MME group IDs.
Voice over IP (VoIP) subscribers anchored in the IP Multimedia Subsystem (IMS) network can move out of an LTE coverage area and continue the call over the circuit-switched (CS) network through the use of the Single Radio Voice Call Continuity (SRVCC) feature. The smooth handover of the VoIP call does not require dual-mode radio.
To support SRVCC functionality on the MME, an Sv reference point is included providing an interface to the enhanced Mobile Switching Center (eMSC) server responsible for communicating with the MME during the handover process.
The MME supports the creation of emergency bearer services which, in turn, support IMS emergency sessions. Emergency bearer services are provided to normally attached UEs and to UEs that are in a limited service state (depending on local service regulations, policies, and restrictions).
When APN selection is based on wild-carded APN-Information, the Update-Location-Request of S6a interface will now contain the Active-APN list along with Specific-APN-Info under the list. Below is the new definition of both the AVPs:
|
l
|
Service-Selection and MIP6-Agent-Info AVPs were NOT present under Active-APN level if Specific-APN-Info is present.
|
Service-Selection, MIP6-Agent-Info and Visited-Network-Identifier AVPs will be present under both Active-APN as well as Specific-APN-Info AVP.
|
l
|
Traffic analysis — uplink DSL, downlink DSL and total DSL traffic including daily weekly, and monthly aggregation/distribution.
|
IMPORTANT: The DSL reports can be generated only when DSL is configured as an APN group during MUR software installation/upgrade.Except the TopN% DSL subscribers, all other DSL reports can be viewed under the DPI tab by selecting appropriate dimensional filters.
IMPORTANT: The discrimination between DSL and UMTS traffic will be based on the APN Name attribute in the EDR file.Release 12.0 onwards, for all new deployments of MUR that use either Sun Netra X4270 or UCS C460 M2 server and run Red Hat Linux, L-ESS is NOT required as the ASR 5K EDR module can be configured to push the xDRs directly to the MUR reporting server. Push from ASR 5K is the Cisco recommended deployment model. Currently, L-ESS is supported only on Solaris platforms. Existing deployments where L-ESS is installed, to pull EDRs from ASR 5K, may continue with their deployment model in the 12.0 version of MUR Software Release and later.
MUR has the capability of exporting reports in Comma Separated Value (CSV) format in addition to PDF and Excel formats. This can be accomplished through the GUI by clicking the csv icon available in the tabular representation of all the reports in the HOME and DPI tabs.
In this release, MUR no longer supports the limitation of selecting only 15 bulkstats counters/indices at a time. Now, there is no defined limit as such; users are allowed to select any number of counters and indices simultaneously.
Charts will not be displayed if more than 15 indexes or 4 counters are selected. However, the data will be displayed in the Table tab of the BS/KPI reporting page.
MUR generates HTTP User Agent (UA) reports and/or UA group reports that are primarily used for ASR 5000 based Modem tethering detection.
The MUR solution also provides a utility to export Top N User-Agent list to a text file based on the given level of tethered traffic. This text file contains pre-formatted CLI file with the configured ruledefs and group-of-ruledefs that need to be applied to the ASR 5K system.
IMPORTANT: Currently, MUR does not support UA report generation for historical data as the data tables does not contain User Agent, APN, and TAC. Also, note that any changes made to the APN/TAC/UA group configurations will not be applied to the old data.The reporting EDR file contains multiple attribute fields like sn-start-time and sn-end-time; some of them are considered mandatory depending on the gateway and reporting types.
Currently, MUR mandates sn-start-time and sn-end-time fields in the flow EDR. If the EDR contains the fields sn-flow-start-time and sn-flow-end-time then MUR will pick values from these fields. However, the sn-flow-start-time and sn-flow-end-time fields are not mandatory.
In a particular deployment, if the EDR receives only sn-flow-start-time and sn-flow-end-time fields, then the mandatory settings for sn-start-time and sn-end-time should be disabled through the System menu on the GUI.
In the current release, the following limitations were imposed with respect to user permissions and privileges:
|
l
|
All MUR administrators have access to USERS and GROUPS menu in the Admin tab available on the MUR GUI.
|
|
l
|
Administrator with admin user name will have the rights to modify and delete all the MUR users’ accounts. Only users with admin user name can modify its own password. Only admin user will be able to delete any administrator or operator user accounts.
|
|
l
|
Administrator other than users with admin user name will have rights to delete the MUR users except admin user and modify user accounts except their passwords.
|
|
l
|
After modifying user role from Administrator to Operator and vice-versa, the user should alter the configuration on the GUI to lock/unlock the user account accordingly.
|
In this release, a custom Red Hat Enterprise Linux OS (Cisco MITG RHEL v5.5) has been introduced to support MUR running on the Cisco UCS platforms.
Release 12.0 onwards, MUR recommends using UCS C460 M2 server running MITG Customized RHEL 5.5. For information on the complete hardware recommendations and file system supported, refer to the Mobility Unified Reporting System Overview chapter in the Cisco Mobility Unified Reporting System Installation and Administration Guide. For the OS installation information, refer to the Cisco MITG RHEL v5.5 OS Application Note.
IMPORTANT: The Cisco MITG RHEL v5.5 OS is a custom image that contains only those software packages required to support compatible Cisco MITG external software applications. Users must not install any other applications on servers running the Cisco MITG v5.5 OS. For detailed software compatibility information, refer to the Cisco MITG RHEL v5.5 OS Application Note. On selecting multiple counters/indices or a huge data range on the Bulkstats and KPI reporting pages, the MUR server may experience some delay in fetching the report information. If the time taken for this activity is beyond the expected threshold, then these tasks are automatically scheduled to be reported offline at a later period.
An automated offline script at the server side runs every 1 minute to check if the requested report information is available. When it is ready, the server makes it available on Background Task Manager tab present on the GUI. These offline reports are generated in Excel format and provided to users as a zip file.
The current release of MUR allows users to search the bulkstats (BS) counters using the Counters text box newly added in the Bulkstats reporting page, and also find the CLI-equivalent counter names by selecting by CLI Name check box.
With the auto-complete feature available in the Counter text box, you can just key in a few characters and search the counters easily.
MUR users have been provided the flexibility to configure multiple SGSN IP addresses under one SGSN group using “ * ”. The SGSN group configuration can be performed on the GUI through System > Reports > SGSN groups menu.
MUR architecture is redesigned so that KPI parser and Bulkstats (BS) parser does not coexist and they function independently from release 12.0 onwards.
The KPI parser now calculates only the values of KPIs for which the alarms are configured through the GUI. This parser uses the information stored by BS parser in the database (DB) for KPI calculations and for sending alarms. This avoids reparsing of the same file and redundant connections to the DB.
KPI parser generates alarms only when the alarm functionality is enabled through the SNMP Configurations option available on the GUI under the System menu.
In this release, the Top N Subscribers Report and Top N VCD Subscribers Report are available per week and month.
Apart from custom reporting, the support for e-mailing weekly/monthly reports and all alarms including KPI alarms is made available in this release.
|
1
|
Weekly Reports and Monthly Reports URL will be e-mailed to configured e-mail users at the start of the week and at the start of the month
|
In this release, a new parameter “Available Port Range for MUR Components (200 Ports)” has been introduced during the MUR installation. With this parameter, the user can either accept the default port range or enter a new port range when the default ports are not available.
Please note that the user is required to enter only the start port number as the end port number will be populated automatically based on the start port number. If any of the port/ports in the specified range is/are busy then the installer throws error and prompts the user to enter new start port number.
The ASR chassis works in conjunction with the MUR application to facilitate tethering detection on the chassis. The EDRs generated by the chassis will be enhanced to include OS signatures.
IMPORTANT: Use of Smartphone tethering detection feature requires that a valid license key be installed. Contact your local Sales or Support representative for information on how to obtain a license.MUR processes flow-EDR files containing OS signature and IMEI field, HTTP files containing User Agent and IMEI field, and populates the following set of data in the respective database files.
|
l
|
Laptop (USB Dongles device group) - User Agent data - Identifies the browser from which the HTTP or WAP request is generated from.
|
|
l
|
Laptop (USB Dongles device group) - OS Signature data - Applications and Operating systems running on the smartphone are device-specific
|
MUR allows the user to enter dongle TACs through the GUI. This in turn allows MUR to identify all laptop OSs and Laptop UAs in the network by mapping the user identified dongle TACs to the corresponding laptop OS and laptop UAs for a flow. All other TACs could either be smartphone TACs or simplephone TACs. If MUR finds a laptop OS or laptop UA matching to a smartphone TAC, MUR will mark the flow as tethered and put into a tethered DB file. These database files are then pushed to all gateways under the /mnt/hd-raid/data/databases/ directory immediately or at a configurable intervals.
MUR provides the required data for tethering detection to the chassis. ECS software running on the chassis plays a vital role in the tethering detection. For information on how the detection is performed, see the 12.2 Enhanced Charging Services Administration Guide Addendum.
The EDR attribute “sn-volume-amt” reports the total uplink/downlink packets/bytes during a flow. This also contains the packets/bytes dropped and retransmitted by ECS.
With the use of “sn-volume-amt” counters, the report may not be an accurate representation of the packets/bytes actually downloaded by the subscribers. This might result in over-charging or over-reporting (the volume) of the subscribers.
MUR provides the flexibility to choose among legacy “sn-volume-amt” or newly added counters “sn-charge-volume” to count the volume. By default, MUR will use “sn-volume-amt” to count the volume.
In the current release, MUR can be used in “Offline Subscriber Search Only” mode. In this mode, MUR will not parse incoming EDR files, so no online reports will be generated.
It will move the incoming EDR files to archive directory, so that you can avail “Offline Subscriber Search Reports” only. By default, this mode is turned off. To run MUR in Offline Mode, set parameter value as “True”. To turn off Offline Mode, set the parameter value as “False”.
In 12.0 and earlier releases, RDP was considered as a region. So, all reports were based on RDP. Whenever an RDP is configured, internally MUR used to create corresponding region for the same. However, in release 12.2 and beyond, one gateway's files will be processed by two or multiple RDPs. In that case, RDP does not stand as a region. So, reports will be required across all the RDPs under one specific region.
Particularly, when there are multiple such regions where each region has more than one RDPs, this feature becomes more important. A different case for the requirement of this feature is a region where there are multiple gateways and they are processed by different RDPs. In that case, per RDP based reports will not make sense, rather, region based reports will be required.
In this release, MUR allows users to create individual regions, and add RDPs to those regions. All the gateways must be associated with RDP(s) or NOC and not to a region.
Along with the support for string-based MSISDNs (called as NAI: Network Access Identifier) of HA/PDSN (CDMA), subscriber search has been enhanced to include options to search by more dimensions like IMEI, Subscriber Port, etc.
The MUR GUI provides user with options to select type of search dimension as well as fields/columns that will appear in excel report. For example, user can select Search By MSISDN for searching subscribers having numeric MSISDNs, NAI for searching subscribers having string-based MSISDNs of HA/PDSN (CDMA).
Based on the reporting requirements, the user can add/remove the EDR fields from Optional Fields list to Report Fields list. Users can request an e-mail with report attached, while entering a search request.
The mandatory fields present at the time of search will be included in output CSV report. The fields applicable to flow EDRs will be present in flow CSV report. Fields applicable to HTTP EDRs will be present in Http CSV report.
MUR supports additional ports, as listed on IANA site, starting from 0 to 1600 and each of them are mapped to respective protocols.
In this release, MUR allows the user to select from the available port range at the time of installation.
The granularity of access controls to user is being extended to ensure that access to reports is controllable by the user. This implies that the user is allowed to configure the granularity settings based on which the reports will be generated in real-time. For example, if granularity 5 is configured, then data will be parsed and report will be viewed with 5 minutes granularity.
The EDRs are processed as frequently as possible allowing reports to be generated shortly after the period to which they apply. Granularity support is currently provided for DPI and HTTP Content Type Summary reports.
MUR makes the MEEBO video/voice protocol available as P2P protocols by default. The meebo-audio is now mapped to voip, meebo-video to video and meebo-unclassified to streaming category.
|
l
|
Reports based on HTTP Services: This feature extends the definition of a service from host name to include a URL or part of a URL and/or port number. HTTP services can be defined as a combination of Host name, Content type, and Part of URL.
|
|
l
|
Reports on Top N Device groups vs Top N Hosts and vice-versa: These reports are possible from the MUR GUI through HTTP tab and Custom Reporting option under Available Reports menu.
|
|
l
|
Video Usage Monitoring Report: Through this custom TopN reporting feature, it is possible to monitor and report the video traffic usage as and when needed. This report is mainly required to identify TopN hosts for video traffic and also to determine the biggest sources of video traffic, which drives the network load at a greater extent.
|
HTTP content type will be used to identify the video traffic. Ideally video traffic should be derived from flow-EDRs. Since the video usage monitoring report is generated based on HTTP content type, only HTTP traffic will be counted.
|
l
|
Report based on Cell Location: This feature allows the usage to be reviewed by Cell ID either as a Top N list of usage by location or a list of fixed locations to be monitored (for top N subscribers per cell) or as a filter on reports (comparable to SGSN group or Device group).
|
On selecting Location Group filter from the Filter selection panel, the following reports can be derived:
TopN subscribers per cell report can also be generated but through the TopN Search tab under Custom Reporting.
|
l
|
Report for Roaming Monitor: The concept of “Roaming Partner Group” is introduced for this reporting. Roaming partner can be defined using MCC-MNC pair as well as SGSN group. Each roaming partner can have multiple MCC-MNC pairs and SGSN groups.
|
MUR users should manually configure MCC and MNC through System menu, and then map this MCC-MNC combination with the roaming partner.
|
l
|
Reports based on HTTP Service Profile: Service Profile is defined as the group of rulebases. Hence, for the service profile reports to be fetched, rulebase name is the mandatory input required from the user. The “Rulebase” name should be added and then a Service Profile must be created to map with the rulebases.
|
|
l
|
Report on Top N Unknown Ports: This report highlights the top N ports for which traffic is classified as either unidentified or unknown. This report can be viewed through the link Edr unknown port infos under the System menu.
|
|
l
|
Reports based on Session: This report provides the statistical analysis of user sessions over the session duration. A session is defined as the unique combination of GGSN address and charging identifier. Charging identifier is used together with GGSN address to identify all records produced in SGSN(s) and GGSN involved in a single PDP context.
|
MUR now supports traffic type detection for P2P protocols such as Skype, Gtalk, MSN, Yahoo, and Oscar with the use of “traffic-type” attribute present in the EDR fields. Based on the value of this EDR attribute, the data will be classified to respective protocols.
TopN IP Traffic Report is no longer supported. MUR now supports TopN HTTP Hosts report, which can be used instead. This report uses “ip-server-ip-address” Flow-EDR attribute.
In Release 12.2, the Mobile Video Gateway software can be integrated with a GGSN (Gateway GPRS Support Node) in a GPRS/UMTS (General Packet Radio Service/Universal Mobile Telecommunications System) network.
For more information, see the Mobile Video Gateway Administration Guide for Release 12.2.
This section provides information on new Network Address Translation (NAT) features in Release 12.0.
This release provides support for H323 ALG that is designed to traverse NAT by inspecting and altering information contained in existing H323 messages as they pass through the NAT. It can alter address and port information in registration, call signaling and automatically opening pinholes in the NAT to allow media flow.
|
l
|
Call Transfer: The Call Transfer supplementary service enables the served user (User A) to transform an existing call with a User B (primary call) into a new call between current User B and a new User C (transferred-to user) selected by served user A.
|
|
l
|
Call Hold: The Call Hold supplementary service allows the served user, which may be the originally calling or the called user, to interrupt communications on an existing call and then subsequently, if desired, re-establish (i.e. retrieve) communications with the held user.
|
|
l
|
Call Diversion: Call Diversion supplementary service permits a served user to have incoming calls addressed to the served user's number redirected to another number; on busy service, it enables a served user to have calls redirected to another endpoint; on No Answer, it enables a served user to have calls addressed to the served endpoint's number and redirected to another endpoint if the connection is not established within a defined period of time.
|
|
l
|
Call Waiting: The Call Waiting supplementary service permits a busy user to be informed of an incoming call while being engaged with one or more other calls.
|
|
l
|
Call Offering: The Call Offering supplementary service on request from the calling user, enables a call to be offered to a busy user and to wait for that called user to accept the call, after the necessary resources have become available.
|
An application layer gateway, at the Firewall/NAT, examines all the H323 packets and modifies the packet such that all the private addresses are replaced by public addresses. It also opens all the pinholes required for successful call establishment. A NAT aware endpoint establishes end-to-end media session through FW/NAT without the need of ALG. Any TCP connection or UDP packet sent from the internal network through the firewall opens a pinhole dynamically in the firewall. This pinhole allows incoming messages to be sent from the destination of the TCP connection or the UDP packet. The pinhole stays open as long as the network sends information through the pinhole to the same destination.
If an end point supports NAT traversal, H323 ALG disables itself so that end point directly opens required pinhole and establishes media path between them. The ALG will not manage any pinhole for media traversal across Firewall/NAT for NAT aware clients. By default, the ALG will bypass all the clients that support H460.18/19 and H460.23/24.
For more information, see the Network Address Translation Administration Guide.
This section provides information on new Network Address Translation (NAT) features in Release 12.2.
Stateful NAT64 is a mechanism for translating IPv6 packets to IPv4 packets and vice-versa. The IPv4 address of IPv4 server/host in an IPv4 network is obtained to and from IPv6 addresses by using the configured stateful prefix. The IPv6 addresses of IPv6 hosts are translated to and from IPv4 addresses by installing mappings in the usual NAT manner.
NAT64 is applied on traffic based on the rule match (Destination based NATing). If NAT64 has to be applied, then the NAT64 will translate and forward them as IPv4 packets through the IPv4 network to the IPv4 receiver. The reverse takes place for packets generated by hosts connected to the IPv4 network for an IPv6 receiver. If NAT64 is not applied on the IPv6 packet, then the IPv6 packet will not be translated and sent as is (NAT bypassed) and will be routed within the IPv6 network to the destination.
NAT64 will not be applied for packets whose destination IP address does not match a pre-defined prefix. NAT64 will be applied only for packets whose destination IP address matches a pre-defined prefix. The pre-defined prefix is configurable, and it can be a single prefix or a group of prefixes.
For more information, see the Network Address Translation Administration Guide.
TCP Proxy support is now available for Lawful Intercept on the PDG/TTG. Contact your local sales representative for detailed information.
The PDG/TTG now supports the sending of a notification to LI administrators when an existing LI target provision has been modified or deleted. Contact your local sales representative for detailed information.
TCP Proxy support is now available for Lawful Intercept on the PDSN. Contact your local sales representative for detailed information.
The PDSN now supports the sending of a notification to LI administrators when an existing LI target provision has been modified or deleted. Contact your local sales representative for detailed information.
The PDSN now has the capability to send intercepted information in TCP format. Contact your local sales representative for detailed information.
This section provides information on new Packet Data Network Gateway (P-GW) features in Release 12.0. Additional information on these features can be found in the Cisco ASR 5000 Series Packet Data Network Gateway Administration Guide and the Cisco ASR 5000 Series Command Line Interface Reference.
In case when UE_ONLY BCM was received from PCRF, IMSA terminated the call for P-GW/GnGp P-GW because BCM of UE_ONLY was not supported.
When BCM of UE_ONLY is received from PCRF, P-GW/GnGp P-GW will not terminate the call. This is applicable to all dictionaries.
New policy-control bind-default-bearer CLI command will bind all the PCC dynamic or pre-defined rules coming from PCRF to the default bearer in the following circumstances:
|
l
|
If the P-GW gets a rule with QCI/ARP other then the default bearer, it will ignore such rules and send a response that the rule could not be installed.
This command will not work for dedicated bearers (secondary PDP contexts). If the P-GW gets a PCC dynamic rule, pre-defined rule from PCRF with QCI or ARP different from that of the default bearer, then those rules will be dropped. Secondary bearers initiated by UE will not be supported.
Implemented changes to extend the existing CLI command for allocation-retention-priority to also optionally include enabling of PCI and PVI flags.
The maximum length of the charging rulebase name in List of Service Data Volumes (LOSDV) of P-GW CDRs can be trimmed now with the inclusion of new command gtpp egcdr rulebase-max-length <rulebase_name_max_length>. With this new command, user will have the flexibility to decide the length of charging rulebase name. The user needs to specify the rulebase name length explicitly, between 1 to 63, in LOSDV to use this feature. In case zero is specified, the charging rulebase name would not be trimmed.
For more information, refer the Context Configuration Mode Commands or GTPP Group Configuration Mode Commands chapter of the Command Line Interface Reference Guide.
Formerly, insignificant zeroes in the monitoring key were stripped off while encoding/decoding it over Gx.
Now, insignificant zeroes are not stripped off while encoding/decoding the monitoring key AVP over Gx. As monitoring key is internally interpreted as an unsigned integer and the insignificant zeroes are not stripped off from the key, the value should be of four bytes in length and not lesser or greater; this will prevent PCRF rejection due to invalid length.
When Gn/Gp interworking with pre-release 8 (3GPP) SGSNs is enabled, the GGSN service on the P-GW supports direct tunnel functionality.
The SGSN/GGSN, when co-residing with the S-GW/P-GW, supports all product-level requirements of the S-GW/P-GW for availability, performance, capacity, security, and O+M.
In case of P-GW with GnGp access, after a P-GW mode to GGSN mode handover, SGSN_CHANGE(0) Event trigger and 3GPP-SGSN-Address needs to be sent. The system shall send AN_GW_CHANGE (21) Event-Trigger and IPv4 SGSN address in the AN-GW-Address AVP. This is because SGSN-Address would not have been valid in the case of P-GW with S5/S8 and, hence, SGSN_CHANGE(0) would not be meaningful after a P-GW mode to GGSN mode handover.
The P-GW supports GRE generic tunnel interfaces in accordance with RFC-2784, Generic Routing Encapsulation (GRE). The GRE protocol allows mobile users to connect to their enterprise networks through GRE tunnels.
GRE tunnels can be used by the enterprise customers of a carrier 1) To transport AAA packets corresponding to an APN over a GRE tunnel to the corporate AAA servers and, 2) To transport the enterprise subscriber packets over the GRE tunnel to the corporation gateway.
The corporate servers may have private IP addresses and hence the addresses belonging to different enterprises may be overlapping. Each enterprise needs to be in a unique virtual routing domain, known as VRF. To differentiate the tunnels between same set of local and remote ends, GRE Key will be used as a differentiation.
GRE tunneling is a common technique to enable multi-protocol local networks over a single-protocol backbone, to connect non-contiguous networks and allow virtual private networks across WANs. This mechanism encapsulates data packets from one protocol inside a different protocol and transports the data packets unchanged across a foreign network. It is important to note that GRE tunneling does not provide security to the encapsulated protocol, as there is no encryption involved (like IPSec offers, for example).
|
l
|
Carrier protocol-protocol that does the encapsulating. For example: GRE, IP-in-IP, L2TP, MPLS and IPSec.
|
|
l
|
IMPORTANT: This feature is license dependent. Please contact your local sales representative for more information.gtpumgr now receives IPSec tunnel notifications from IPSec. gtpumgr now updates all sessmgrs with NPU flow information for the tunnel that is received from IPSec.
gtpumgr also notifies all sessmgrs of peer info. so that when any bearer setups for that peer, corresponding IPSec tunnel info. is used for data forwarding.
GTP-U Echoes Sent through IPSec Tunnel for a Peer Once the IPSec Tunnel to the Peer is Set Up
With IPSec tunnels, if gtpumgr restarts, the IPSec tunnel info is now synced up with the IPSec subsystem and sessmgr.
CHANGE_IN_SERVING_NODE trigger is an extension to the CHANGE_IN_SGSN trigger. However, for the purpose of backward compatibility, both triggers are retained. The P-GW sends them in the following manner.
|
l
|
SERVING_NODE AND SGSN is configured on the CLI, system sends SERVING_NODE_CHANGE.
|
|
l
|
|
l
|
SGSN alone (older OCS), then the current behavior of sending CHANGE_IN_SGSN_IP_ADDRESS trigger is retained.
|
|
l
|
SERVING_NODE alone (newer OCS), then the new trigger CHANGE_IN_SERVING_NODE would be sent.
|
MSCC (quota) checkpointing is now handled as part of normal session recovery. MSCC checkpointing occurs randomly (~ 1-2 times within every 60 seconds) on every MSCC update. The MSCC checkpoint will be sent to the peer chassis only if there is a change in MSCC information.
IP Security (IPSec) on the S5 interface is a node-to-node IKEv2 tunnel that can be configured to assume the characteristics of either a pre-configured tunnel or a dynamic tunnel.
Pre-configured node tunnels are fully qualified IPSec tunnels. Each IPSec tunnel is configured with parameters including pre-shared key, local and remote IP addresses, crypto hashes, groups, algorithms and the access control list (ACL).
Node-to-node dynamic tunnels are generated dynamically as the connections are initiated by different nodes in the LTE network. Each IPSec tunnel does not need to be pre-configured for each required parameter, instead it uses a common template for some parameters, like crypto algorithms, hashes, and groups. Other parameters are fetched dynamically from the tunnel requests like IP addresses and traffic selectors. Authentication information is fetched dynamically via certificates.
Typically, the S-GW initiates an IPSec tunnel to the P-GW. The P-GW service is responsible to verify the configuration and use an IPSec API to make the P-GW listen on the service address for IKE requests.
When configured for IPSec, the S5 Interface carries GTP-C signaling traffic and GTP-U data traffic that flows through an IPSec tunnel.
Local QoS policies can be used to control different aspects of a session, such as QoS, Data Usage, Subscription profiles, or Server Usage, by means of locally defined policies.
Local QoS policies are triggered when certain events occur and the associated conditions are satisfied. For example, when a new call is initiated, the QoS to be applied for the call could be decided based on the IMSI, MSISDN, and APN.
IMPORTANT: This feature is license dependent. Please contact your local sales representative for more information.Toward P-GW, there is collision scenario when S-GW and P-GW both initiate a tunnel at the same time; however, one of them will terminate.
When enabled through a feature license key, the system includes NEMO support for a Mobile IPv4 Network Mobility (NEMO-HA) on the P-GW platform to terminate Mobile IPv4 based NEMO connections from Mobile Routers (MRs) that attach to an Enterprise PDN. The NEMO functionality allows bi-directional communication that is application-agnostic between users behind the MR and users or resources on Fixed Network sites.
The same NEMO4G-HA service and its bound Loopback IP address supports NEMO connections whose underlying PDN connection comes through GTP S5 (4G access) or PMIPv6 S2a (eHRPD access).
IMPORTANT: This feature is license dependent. Please contact your local sales representative for more information.P-GW Supports Average Throughput Per Active User of 10 Kbps on Uplink and 50 Kbps on Downlink
The P-GW service now supports average throughput per active user of 10 Kbps on uplink and 50 Kbps on downlink.
P-GW Supports Throughput Per Active Video Streaming User Device of 256Kbps on Uplink and 1Mbps on Downlink.
The P-GW service now supports throughput per active video streaming user device of 256Kbps on uplink and 1Mbps on downlink.
Previously, for Default-EPS-Bearer QoS, IMSA validation for QCI ranges 1-9 and 128-254 were considered valid (as per spec).
The IPSec implementation for LTE is only node-to-node. Any IPSec tunnel will handle multiple subscriber GTPU traffic. The IPSec tunnel is generated dynamically as the connection is initiated by nodes in the LTE network. Each IPSec tunnel uses a common template for parameters, such as crypto algorithms, hashes, groups, etc. Other parameters are fetched dynamically from the tunnel requests, such as IP addresses and traffic selectors. Authentication information is fetched dynamically via certificates.
For LTE nodes, IPSec tunnels can be setup for control and data traffic carried over S1-MME, S1-U, S11, and S5.
The configuration monitor utility will perform a show configuration command every 15 minutes and compare the subsequent output to determine whether the information has changed. The configuration is defined as having changed when the current configuration differs from the previous snapshot. If a configuration change is indicated, then an SNMP trap is sent.
Support for Event Trigger UE_IP_ADDRESS_ ALLOCATE and UE_IP_ADDRESS_RELEASE
Added support for displaying event-masks and statistics for Event-Triggers UE-IP-Address-Allocate and UE-IP-Address-Release.
The P-GW supports X.509 certificate-based peer authentication for IPSec tunnels over the S5 interface.
This section provides information on new Packet Data Network Gateway (P-GW) features in Release 12.2. Additional information on these features can be found in the Cisco ASR 5000 Series Packet Data Network Gateway Administration Guide and the Cisco ASR 5000 Series Command Line Interface Reference.
1:1 NAT IP was either used for NAting IPv4 or IPv6 traffic, but not both. There was no 1:1 NAT64 binding table. All downlink traffic received on 1:1 NAT64 IP was translated to client IPv6 addr in ACL clp, irrespective of the interface id used for uplink.
1:1 NAT IP can be shared by IPv4/IPv6 traffic. 1:1 NAT64 binding table is maintained to store the interface ID/prefix. The downlink traffic is properly translated based on the binding table. The interface ID/prefix are obtained form the binding entry.
Verified that P-GW is able to process UE time zone IE from S5/S8 from MME/S-GW. Also, P-GW-PCRF interaction has been verified.
Traditionally, transactional models have been based on registered subscriber sessions. In an “always-on” deployment model, however, the bulk of user traffic is registered all of the time. Most of these registered subscriber sessions are idle a majority of the time. Therefore, Always-On Licensing charges only for connected-active subscriber sessions.
A connected-active subscriber session would be in “ECM Connected state,” as specified in 3GPP TS 23.401, with a data packet sent/received within the last one minute (on average). This transactional model allows providers to better manage and achieve more predictable spending on their capacity as a function of the Total Cost of Ownership (TCO).
Bearer ID was displayed as “0” in the output of CLI command show ims-authorization sessions all for all except access type 3GPP-GPRS.
Bearer ID is displayed as “NA” in the output of CLI command show ims-authorization sessions all for all except access type 3GPP-GPRS.
Configuration Changes to Allow Gy-based User Sessions to Continue During OCS Failure and Ability for P-GW/HA to Continue Data Session for Fixed Time/Quota During OCS Outage
Existing servers-unreachable command has been modified. If set, new configuration options would:
|
l
|
Determine the gateway behavior if OCS becomes unreachable, either due to transport failure or due to message timeouts owing to network congestion.
|
Every bearer in a P-GW (or pdp context in case of GGSN) belonging to the same subscriber consumed one ECS license each. When a subscriber had multiple bearers/pdp contexts, then ECS licenses were exhausted before the actual limit for subscribers was reached, which resulted in new calls being denied.
Now, a single ECS license is consumed per subscriber, irrespective of the number of default or dedicated bearers (primary or secondary pdp contexts) it may have. ECS licenses will be exhausted only after reaching the configured limits.
Added support for grp-of-ruledefs and predefined-dynamic-rule. Added DNS analyzer changes for storing IPv4, IPv6 and CNAME entries and removing the config lists on “no” CLIs. Added CLI command for adding ip server-domain-name ruledef and creating IP table per rulebase.
Functional Behavior Change for Prefix Len Value in IPv4 Home Address Reply Option in PBA
If CLI command ip pool has subscriber-gw-address configured, then value configured will be sent in IPv4 default router address option in PBA.
In addition, value of prefix len in PBA will be set to mask of the pool if mobility-option-type-value standard is configured in LMA service.
CLI command added to enable/disable addition of the sequence number to every GTP-U packet coming from Gi interface and going towards Gn/Gp interface. If GTP-U packets are received out of sequence, sequence numbers would allow the packets to be reorded.
|
l
|
Support of DCCA failure handling action=continue with timer (allow session to continue and disconnect after timer)
|
With previous virtual-apn CLI command, either cc or imsi could be used to define a selection rule for virtual apn.
Now, virtual-apn CLI command can also be used to define a imsi+cc virtual apn selection rule.
While installing the dynamic and predef rules in LTE scenario, if qci and arp values specified in the rule are of the default bearer, then TFT is not sent to MS. Also, if qci and arp are not specified in the rule, then the configuration of the default bearer will be used and TFT is not sent to MS.
CLI command ipv6 pool <name> range <start_address end_address> was allowing interface ID as part of configuration.
When interface ID part of the IPv6 address is configured as part of range, interface ID is cleared and a warning message is displayed.
TCP Proxy support is now available for Lawful Intercept on the P-GW. Contact your local sales representative for detailed information.
The P-GW now supports the sending of a notification to LI administrators when an existing LI target provision has been modified or deleted. Contact your local sales representative for detailed information.
P-GW may be configured with Diameter peer information for a pair of primary and secondary Online Charging Server (OCS). In this case, P-GW shall select the secondary OCS when the primary OCS is not available. P-GW shall perform an AAAA DNS query (IPv6) on FQDN (from Diameter peer information) to obtain the IP addresses of primary and secondary OCS nodes. P-GW shall then establish CER/CEA connectivity toward both OCS nodes. For normal Gy Diameter Credit-Control Application (DCCA) requests, the P-GW shall use the primary OCS connection.
Previously, the system cleared all subscribers to the downed eGTP-C peer after echo timeout. This is still the default system behavior.
New CLI configuration has been added to allow the following alternate behavior in peer outage/restart scenarios:
|
2
|
When the peer comes back, only clear subscribers if the recovery/restart counter has been incremented on the peer.
|
The allowed range of content-id configurable was changed to maximum 31-bit value. The allowed range of service-identifier configurable was changed to maximum 31-bit value. The following CLI commands help text has been changed to display maximum value as 2147483647 instead of 65535:
|
l
|
|
l
|
|
l
|
Old behavior: The maximum value allowed to be configured for content-id and service-identifier was 65535 (maximum 16-bit value).
New behavior: The maximum value now allowed to be configured for content-id and service-identifier is changed to 2147483647 (maximum 31-bit value).
If default bearer QoS/APN AMBR change is reported in CCR-U but not authorized, the access side procedure is rejected in case of 3G call on P-GW.
If default bearer QoS/APN AMBR change is reported in CCR-U but not authorized, the access side procedure is not rejected in case of 3G call on P-GW.
P-GW RAR Handling While Waiting for CCA Issue for Gy OUT-OF-CREDIT
In the case when RAR was received from PCRF when there is a pending auth state, PCEF responded with a permanent failure (Unable to Comply). As per RFC 3588, the client/server should not retry the request if there is a permanent failure in a response. PCEF should not respond with permanent failure and instead let the PCRF retry the request after some time.
Since there are no transient failures fitting this category, using protocol error “Unable to Deliver”.
|
l
|
regardless of Gating Expire Time expiry, PCEF respond and shall immediately send CCR-U, Rating-Group/Service-Identifier, Reporting-Reason = forced_reauth.
|
|
l
|
|
l
|
when user traffic comes and Gating Expire time expires, PCRF shall send CCR-U, Reporting-Reason = quota_exhausted
|
|
l
|
Support has been added in minidiameter to send Gating-Expire-Time AVP in response to CCR-FINAL (for FUA-Terminate and 4012 case).
mscc->grant.gating_expire_time is at mscc level and represent those MSCCs for which Gating-Expire-Time AVP was received from the server.
time_t gating_expire_time /* and indicates the time for which PGW
The P-GW currently supports the following Release 9 3GPP specifications. Most 3GPP specifications are also used for 3GPP2 support.
|
l
|
3GPP TS 23.401: General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access
|
|
l
|
3GPP TS 29.060: General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp interface
|
|
l
|
3GPP TS 29.061: Interworking between the Public Land Mobile Network (PLMN) supporting packet based services and Packet Data Networks (PDN)
|
|
l
|
3GPP TS 29.272: Evolved Packet System (EPS); Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) related interfaces based on Diameter protocol
|
|
l
|
3GPP TS 29.274: 3GPP Evolved Packet System (EPS); Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for Control plane (GTPv2-C); Stage 3
|
|
l
|
3GPP TS 29.275: Proxy Mobile IPv6 (PMIPv6) based Mobility and Tunnelling protocols; Stage 3
|
|
l
|
3GPP TS 32.240: Telecommunication management; Charging management; Charging architecture and principles
|
|
l
|
3GPP TS 32.251: Telecommunication management; Charging management; Packet Switched (PS) domain charging
|
|
l
|
3GPP TS 32.298: Telecommunication management; Charging management; Charging Data Record (CDR) parameter description
|
|
l
|
3GPP TS 32.299: Telecommunication management; Charging management; Diameter charging application
|
Added support for grp-of-ruledefs and predefined-dynamic-rule. Added DNS analyzer changes for storing IPv4, IPv6 and CNAME entries and removing the config lists on “no” CLIs. Added CLI command for adding ip server-domain-name ruledef and creating IP table per rulebase.
|
l
|
In SDF level accounting, buckets are created and maintained using the Reporting-Level AVP value present in Gx message. The following are the accounting keys currently supported:
|
|
l
|
Existing volume/time limit is applied for session level in accounting policy. New CLI configuration added at SDF level.
|
|
l
|
Service Data Volume Limit: Volume Limit reached for a specific flow. The container for this change condition will be cached by the P-GW and the container will be in an ACR Interim/Stop sent for partial record (Interim), final Record (Stop), or AII trigger (Interim) trigger.
|
|
l
|
Service Data Time Limit: Time Limit reached for a specific flow. The container for this change condition will be cached by the P-GW and the container will be in an ACR Interim/Stop sent for partial record (Interim), final Record (Stop), or AII trigger (Interim) trigger.
|
|
l
|
Updated mobility option type values for IPv4 Home Address, Address Acknowledgement, GRE Key, and Default Router options to the IANA assigned values.
|
|
l
|
PGW-Relocation-Indication AVP support added for S6b to support stale session notification/deletion.
|
|
l
|
S6b updated to define the IPv6 pool name AVP, and the P-GW supports the IPv6 pool name coming from AAA. Added support for Framed-IPv6-Prefix and Framed-Interface-ID.
|
|
l
|
The diameter incoming message parsing should take care of the absence of the “M” bit in these AVPs correctly.
Static rules should be applied only to default bearers. A check for this was missed in the DCCA init routine which decides whether a sub session is online charged by checking the “charging actions” of all static rules configured in the chassis and the installed pre-defined and dynamic rules.
Now, static rules are considered only for default bearers in the DCCA init routine. For dedicated bearers, only the charging actions of the installed pre-defined rules and dynamic rules decide whether DCCA needs to be enabled.
Unless otherwise stated, the use of the Supported-Features AVP on the Gx reference point shall be compliant with the requirements for dynamic discovery of supported features and associated error handling on the Cx reference point.
The Supported Features here may have M bit set and Feature List ID and Feature List must not have “M” bit set.
The NAI sent in the Mobile Node Identifier field in PMIPv6 will not include the digit prepended in front of the IMSI that is described above.
The current HSGW includes NAI received in EAP, and P-GW also expects this digit to be present. To support removing the leading digit, mobility-option-type-value standard configuration in MAG/LMA service will be used to support S2a MN-ID. There is no behavior change for custom1 and it will continue to work as usual.
Completed P-GW changes to extract IMSI from NAI and handle cases when auth-mode digit is included or removed. mobility-option-type configuration is used and standard is expected to receive PBU without digit prepended.
In both HSGW/P-GW, PBU is expected to have <IMSI>@realm where IMSI field can only be maximum of 16 digits, including auth-mode. If it is more than 16 digits, then it is decoded as invalid IMSI format and IMSI will not be extracted.
In addition, mobility-option-type custom2 configuration has been added for this feature. The standard will continue to work as before.
P-GW does not support traffic shaping for APN-AMBR. Therefore, the keyword shape and its options have been removed from the apn-ambr CLI command in the APN Configuration Mode.
The P-GW needs to report the full IPv6 address assigned to the UE only. There is no need to report the IPv4 address, if assigned to the UE. The P-GW shall use Framed-IPv6-Prefix AVP to report the IPv6 prefix and Framed-Interface-Id to report the interface identifier (IID).
With this support, a UE is able to connect to an emergency PDN and make Enhanced 911 (E911) calls while providing the required location information to the Public Safety Access Point (PSAP).
E911 is a telecommunications-based system that is designed to link people who are experiencing an emergency with the public resources that can help. This feature introduces support for E911-based calls across the LTE and IMS networks. In a voice over LTE scenario, the subscriber attaches to a dedicated packet data network (PDN) called EPDN (Emergency PDN) in order to establish a voice over IP connection to the PSAP. Signaling either happens on the default emergency bearer, or signaling and RTP media flow over separate dedicated emergency bearers. Additionally, different than normal PDN attachment that relies on AAA and PCRF components for call establishment, the EPDN attributes are configured locally on the P-GW, which eliminates the potential for emergency call failure if either of these systems is not available.
Emergency bearer services are provided to support IMS emergency sessions. Emergency bearer services are functionalities provided by the serving network when the network is configured to support emergency services. Emergency bearer services are provided to normally attached UEs and to UEs that are in a limited service state (depending on local service regulations, policies, and restrictions). Receiving emergency services in limited service state does not require a subscription.
|
l
|
|
l
|
UEs that are in a limited service state (due to attach reject from the network, or since no SIM is present), initiate an ATTACH indicating that the ATTACH is for receiving emergency bearer services. After a successful attach, the services that the network provides the UE is solely in the context of Emergency Bearer Services.
|
|
l
|
UEs that camp normally on a cell initiates a normal ATTACH if it requires emergency services. Normal attached UEs initiated a UE Requested PDN Connectivity procedure to request Emergency Bearer Services.
|
The Cisco® ASR 5000 Platform provides 3GPP PPC solution to network carriers in UTRAN/E-UTRAN/cdma2000-1x/HRPD networks.
The Cisco PCC solution is based on 3GPP PCC model and standards, and intelligently extends it such as to simplify the complex and diverse requirements of policy and charging management for global operators.
The PCC solution comprises of Policy and Charging Rules Function (PCRF), Subscriber profile repository (SPR), and other interfacing module like Policy Provisioning Tool (PPT) to implement and control the policy based subscriber access in the existing wireless network as well as service flow based credit control implementation.
Intelligent Policy Control Function (IPCF) provides policy control and charging rule functions in a core network.
IPCF acts as a PCRF functions supplemented with usage monitoring capability that enables policies around data consumption. IPCF interfaces with the PCEF over standard Gx interface for policy management and optionally over
Cisco IPCF is compliant in accordance with 3GPP standard in operator’s core network. Some of the key functions of IPCF are to:
|
l
|
|
l
|
Ensure the PCEF user plane traffic treatment is in accordance with the user's subscription profile
|
For information about the IPCF solution, refer Cisco ASR 5000 Series Intelligent Policy Control Function Administration Guide
Subscriber Service Controller (SSC) is an application that complements and extends the functionality of Intelligent Policy Control Function (IPCF).
SSC uses Subscriber Profile Repository (SPR) data store, to implement the usage control policies in a centralized manner. It also handles account details as well as session state information of the subscriber. SSC can manage the event notification function for PCC, by sending e-mails or text messages to subscribers. SSC provides storage facility for subscriber profile along with centralized management of subscriber policy and quota for your deployment.
For information about the SSC, refer Subscriber Service Controller Installation and Administration Guide.
Cisco Policy Provisioning Tool (PPT) is a Web-based client-server application which provides the user (network operator) a comprehensive use case design experience. It enables the network operator to design a service plan and subscriber profile data modelling at a time with the help of use case design and configuration.
PPT is designed to simplify use case configuration by importing the relevant Policy Control Enforcement Function (PCEF) flow, rules and APN data elements.
PCEF, typically located at the gateway is responsible for enforcing the policy and charging related decisions received from IPCF. PCEF performs service data flow detection as well as gate enforcement for the data flows.
For information about the PPT, refer Policy Provisioning Tool Installation and Administration Guide.
The PPT application is now supported on selected Cisco UCS servers running the custom Cisco MITG Red Hat Enterprise Linux (RHEL) v5.5 operating system (OS).
For detailed hardware platform and hard disk drive partition requirements, refer to the Policy Provisioning Tool Overview chapter of the Policy Provisioning Tool Installation and Administration Guide. For installation information, refer to the Cisco MITG RHEL v5.5 OS Application Note.
IMPORTANT: The Cisco MITG RHEL v5.5 OS is a custom image that contains only those software packages required to support compatible Cisco MITG external software applications. Users must not install any other applications on servers running the Cisco MITG v5.5 OS. For detailed software compatibility information, refer to the Cisco MITG RHEL v5.5 OS Application Note.This section provides information on new Session Control Manager (SCM) features in Release 12.0. Additional information on these features can be found in the Cisco ASR 5000 Series Session Control Manager Administration Guide and the Cisco ASR 5000 Series Command Line Interface Reference.
Level 1: For every new call/event received, the system checks if sessmgr memory-usage is above a threshold value (such as 95 percent). If it is, memory-congestion is triggered and new call messages are rejected with 500 SIP response. Memory congestion is disabled when memory usage drops by a tolerance value (default is 10 percent). This functionality has not been tested.
Level 2: If the sessmgr usage reaches 100 percent, all newly received SIP messages are dropped at the socket layer in that sessmgr except for the BYE message. The new SIP messages are not processed until the memory reaches the threshold value (95 percent).
Bridge Mode: CSCF Session and Performance Counters Incremented for VoIP Calls.
When P-CSCF acts in a bridging mode between two services, the show cscf session counters calls <filter criteria> name <service_name> command now displays separate counters for access and core P-CSCF.
Cscfmgr Does Not Drop Register Requests for which Retries Exceeded When Congestion is Turned On in sessmgr
When cscfmgr (demuxmgr) receives REGISTER request from Network, it fetches a suitable sessmgr for processing REGISTER. If that sessmgr rejects the REGISTER since it is overloaded, cscfmgr will retry another sessmgr. If the system is congested, cscfmgr will retry three times to find a sessmgr. If it fails, then cscfmgr will reject the request with a “503 service unavailable” error response with Retry-after header.
CSCF now supports application/vnd.etsi.aoc+xml MIME type as per spec TS 24.647 and proxies the message without parsing the message body.
The SCM now supports redirection on overload (exceeding session/license limit). Overload conditions arise when the maximum session limit per sessmgr is reached or the license is exceeded.
When the CSCF becomes overloaded, an overload policy can be configured to handle it. When the overload condition is hit, the new registrations (SIP REGISTER messages) reaching the cscfmgr are dropped/rejected/redirected based on the configuration.
When CSCF identifies congestion, it originates UMM_RESPONSE with response code set as 500. Sipapp while forming the response SIP_IPS fills the Retry-after header with a random value between 0 to 10 seconds as per RFC 3261.
CSCF Supports RFC 5621 Message Body Handling in the Session Initiation Protocol (SIP)
CSCF has supported “multipart/mixed” message body parsing. It now also supports “multipart/alternative” and “multipart/related” message body parsing.
For Interactive Traffic class, the P-CSCF/A-BG supports per-service configurable DSCP marking for Uplink and Downlink direction based on Allocation/Retention Priority in addition to the current priorities.
I-CSCF Supports the Ma Reference Point for Interfacing to AS to Support Public Service Identity (PSI) Procedures
I-CSCF, upon receiving the terminating request, checks the subdomain-route list for matches. If a match is found the routing will happen based on it. Otherwise, I-CSCF will do a User Location Query (Location-Information-Request) and proceed normally.
P-CSCF Determines the Type of Authentication Based on the Rules in Annex P.3, 33.203 (860)
P-CSCF Rejects Emergency Calls Based on Local-policy/UE-location-network/SDP
P-CSCF will reject an emergency-call with 380 response based on the following local-policies (only if user is not emergency-registered):
|
l
|
User is a visited-ue and makes an emergency-call. Here, visited-ue is determined based on matching of PANI in INVITE with MCC/MNC configured (new-option).
|
|
l
|
Reject emergency-registration from a visited-ue. visited-ue is determined based on the existing functionality of PANI/default-aor-domain match.
|
|
l
|
RAT change notification is now done along with IPCAN change notification (Sec 5.3.13,Sec 4.4.6.4)
|
|
l
|
Specific Action AVP -CHARGING_ CORRELATION_EXCHANGE is now used for correlation exchange. Previously it was made obsolete.(Sec 4.4.6.5)
|
P-CSCF now provides IPv4-IPv6 interworking functionality between IPv4-only UEs and IPv6-only core network elements (I/S-CSCF) by acting as dual-stack.
To achieve the dual-stack behavior, P-CSCF is configured in two services. The first service (V6-SVC) listens on an IPv6 address. The second service (V4-SVC) listens on an IPv4 address. SIP messages coming from IPv4 UEs will come to V4-SVC and be forwarded to the IPv6 core network through V6-SVC. Similarly, messages from IPv6 core network that come to V6-SVC can be forwarded to IPv4 UEs via V4-SVC.
To meet regulatory requirements that deaf/hearing impaired people must be able to perform text-based communication to other users and government offices, the P-CSCF now supports Global Text Telephony.
Global Text Telephony/Teletype messages must use ITU-T Recommendation T.140 for real-time text according to the rules and procedures specified in 3GPP TS 26.114 with the following clarifications:
|
l
|
For real-time text, RTCP reporting is turned off by setting the SDP bandwidth modifiers “RS” and “RR” to zero.
|
For a forking proxy server, the type of directive indicates whether the caller would like the proxy server to proxy the request to all known addresses at once (parallel), or go through them sequentially (serial) by contacting the next address only after it has received a non-2xx or non-6xx final response for the previous one.
The Session-Priority AVP is now sent in Rf charging messages based on the SIP Resource-Priority header.
Transport Layer Security (TLS) provides confidentiality and integrity protection for SIP signaling messages between the UE and P-CSCF/A-BG. TLS is a layered protocol that runs upon reliable transport protocols like TCP and SCTP.
|
l
|
Use of TLS by Security Mechanism agreement between UE and P-CSCF/A-BG, as per RC 3329 and TS 33.203
|
This section provides information on new Session Control Manager (SCM) features in Release 12.0. Additional information on these features can be found in the Cisco ASR 5000 Series Session Control Manager Administration Guide and the Cisco ASR 5000 Series Command Line Interface Reference.
During Re-Invite, AAR is required to be sent only after 200 OK. Previously, it was also sent for INV message during re-invite procedure.
A new access-profile policy has been added for pcrf-control. This will enable pcrf-policy control to be enabled per access-type.
Unless the pcrf-policy-control is enabled for an access-type or in the default-access-profile, it will be disabled by default.
CLI route command, which specifies that a route lookup should be performed and the request URI modified, has been expanded to allow add, delete, and change options.
During Registration, CSCF stores and manages the capability of UE. When a UE receives a call, the CSCF refers to the capability of that UE, and if the required service is not supported an error response is generated.
CLI has been added to configure UE capability failure to accept or reject with specific response code.
CLI added for displaying Initial Filter Criteria (iFC) in XML format, as per 3GPP TS 29.228 Annex E.
S-CSCF does not need to check subscriber's authentication if authentication flag is set to 0 in MAA message.
Call forwarding failed when History-info header from AS had syntax issue. Now, S-CSCF supports reserved type ( blank, @ ) for History-Info value and forwards the INVITE with History-Info having reserved type ( blank, @ ).
Added support for multi-part ACL. Keywords can now be entered multiple times within a single command to support multi-part ACL in CSCF in the following CLI commands (CSCF ACL Configuration Mode):
|
l
|
|
l
|
|
l
|
|
l
|
Display of Registration timestamp in show sub cscf-only full CLI output
|
When new CLI is enabled, User Name AVP will be filled with Public User ID with URI Scheme in ACR message.
CLI command added to enable the S-CSCF to return only one binding (latest contact) for each registration without including other bindings, if any.
Previously, all RCS-e tags were processed as the same tag. Now, they are processed separately and Rf feature-code AVP is sent accordingly.
Disable UAR/UAA: P-CSCF to select the S-CSCF based on destination aor routing/DNS routing.
If new user-authorization CLI command is enabled, and I-CSCF role is enabled in S-CSCF, I-CSCF will send UAR/UAA diameter message to HSS.
The maximum number of entries for ip localhost CLI command has been increased from 256 to 1024.
When custom volte command is enabled and hostname is configured, S-CSCF will add hostname:service-port in From header of OPTIONS request.
Feature parameter in the ACR must include the feature code based on the P-LGTVTS-Charging-Data.
The CDF address provided by HSS is used when no CDF matches the “prefix and capability based selection criteria”, then:
The CDF address provided by HSS is used when no CDF matches the “prefix and capability based selection criteria”, then:
|
1
|
The CDF address received from HSS will always be treated as a AAAGroup Name. The FQDN/IP and port part of address will be extracted and used as AAAGroup name.
|
The keyword source has been removed from the following command in the CSCF Diameter Selection Configuration Mode.
[ no ] aaa-group name criteria { source aor aor_prefix | subscriber-capability { audio [ only ] | text | video } | subscriber-ip-type { v4 | v6 } } +
[ no ] aaa-group name criteria { aor aor_prefix | subscriber-capability { audio [ only ] | text | video } | subscriber-ip-type { v4 | v6 } } +
Previously, if criteria source aor <aor-prefix> was configured, fetching of aaa group name was done based on source aor. Now, fetching of aaa group name for a subscriber can be based on source aor match or destination aor match.
To support re-arrangement of prefix related configuration, preference will be associated with each diameter selection entry in the diameter selection table. The keyword preference and its options have been added to the aaa-group command in CSCF Diameter Selection Configuration Mode.
If preference is not specified, it is assigned a preference one greater than the last entry's preference in the diameter selection table.
New CLI configures matching criteria for selecting a AAA group name. When a subscriber registers, the selection criteria are compared and the AAA group name from the matching entry will be picked up. The selected AAA group will be used for all HSS interactions for that subscriber. Maximum of 3 criteria can be configured per entry. A maximum of 1024 such entries can be configured.
|
l
|
Ability to retry Register on a second S-CSCF server based on UAR returned capabilities when the first server times out or sends an error response
|
|
l
|
If the implicit timer is configured and the UE time expires, then the system responds with 200OK with Expires-header set to configured implicit-expires time.
When custom volte command is enabled, “TYPE 3” tag in the IOI is not sent to AS. S-CSCF adds orig-ioi parameter in P-Charging-Vector while sending towards AS in all SIP method scenarios (except REG).
MS Status code: 0(IDLE), 1(NORMAL), 2(UNREG), 3(REGISTERED), 4(POWEROFF), 5(1xBUSY), 6(VTBUSY)
The following two protocols have been added to the system’s protocol monitoring utility initiated by the monitor protocol CLI command:
New diameter authentication custom dictionary “aaa-custom5” added for Rf interface to support the following new AVPs:
Multiple bind commands now supported for each NPDB client in CSCF NPDB Client Configuration Mode.
If the identity of the served user of the request was taken from the P-Preferred-Identity header field by its matching a registered wildcarded public user identity and the P-CSCF supports the SIP P-Profile-Key private header extension, The P-CSCF now includes the wildcarded public user identity value in the P-Profile-Key header field, as defined in RFC 5002 [97].
New CLI allows a custom specific header, P-LGUPlus-PRID-Info, which contains the private user id of the user sending any dialogue crating request or any standalone requests, to be added in the message toward nexthop. The addition of this custom header will be done when Proxy-CSCF forwards this message.
New keyword v6port-range in media-bridging CLI command specifies port ranges to be used with IPv6 addresses. Only selected ports from the range specified should be used for media bridging.
CLI has been added to configure UE capability failure to accept or reject with specific response code.
New keyword timeout in release-call-on-media-loss CLI command specifies the media loss timeout value; media loss after timeout value results in call release.
If the AS which is triggered by iFC has a problem, new CLI allows configuration of the reply value for that peer AS.
Fulfilled requirement to add P-LGUPlus-Instance-Info header with value of Public-GRUU generated by S-CSCF towards AS.
AS changes tag in To header for these messages. Now, S-CSCF forwards 183 responses with different To-tag.
New CLI allows a custom specific header, P-LGUPlus-PRID-Info, which contains the private user id of the user sending the REGISTER request, to be added in the REGISTER message towards AS during third party registration.
When the Request URI in the incoming request matches the locally configured PSI, then I-CSCF must not do location query and must route the request based on the internal DNS.
When the S-CSCF does not have the user profile, it initiates the S-CSCF Registration/Deregistration notification procedure, as described in 3GPP TS 29.228 [14]; with the purpose of downloading the relevant user profile and informs the HSS that the user is unregistered.
The S-CSCF will assess triggering of services for the unregistered user, as described in 3GPP TS 29.228 [14]. When requesting the user profile the S-CSCF can include the information in the P-Profile-Key header field in the S-CSCF Registration/deregistration notification.
CLI command added to enable the S-CSCF to fill the server name AVP in MAR and SAR for Cx interface with configured server name.
Session is released when RAR with event INDICATION_OF_RELEASE_BEARER (4) is received from PCRF.
Instead of using a different IPv6 prefix for each subscriber, using shared-prefix pool at VPN level. With this, first 64 bits remains the same for all the users across different session managers.
CLI has been added to support enabling AAR for 180, 183 and 18X responses. If disabled, then AAR will not be sent when system gets 18X from AS or other peers.
|
l
|
CLI has been added to support the NPDB (Number Portability Data Base) feature. NPDB is based on a client server architecture. NPDB client in S-CSCF service performs query for called subscriber number on NPDB server, which returns Routing Number for the query.
NPDB client uses TCP connection to the NPDB server through the sessmgr and maintain a prefix table with 1,000 entries.
Now, CER/CEA messages received without Acct-Application-Id are not considered an error for customer-specific Rf.
New CLI allows a custom-md5 option in authentication configuration.
LIA based on the MS Status from the LIA message. The system can route, accept, or reject-with-error-code the call based on MS Status code from LIA message.
MS-Status-AVP data is now also copied into P-LGT-Term-Status SIP header, which is added by I-CSCF and sent to terminating S-CSCF. Terminating Application server uses this P-LGT-Term-Status SIP header to execute the supplementary features.
New CLI added to control the rate of messages going from S-CSCF to application server (AS) based on Transactions Per Second (TPS).
New CLI enables reg-event package at S-CSCF. System will send 501 “Not implemented” if the CLI is not enabled.
This support is only for INVITE. If PCRF is enabled and PCRF server is down, REGISTER is expected to fail.
CLI command show subscribers enhanced.
Sample show subscribers summary output format:
Session query based on the subscriber number now includes session category (type), starting time, and calling/called number.
Previously, all RCS-e feature tags uses a single ue-capability-failure response code. CLI has been added in route selection, hss selection, ue-capability-failure response code, and ACL configuration to support configuring response codes for each RCS-e feature tag.
If a call is forwarded by AS and the Diversion header is included in INVITE, the header value is used as calling party of CDR.
3GPP “Service-Info-Status” AVP includes a new value “2” (PROVISIONAL_RESP_INDICATION_SERVICE_INFORMATION(2)) in custom dictionary rx-custom01. This indicates that the AAR was triggered for 18x response.
This section provides information on new Serving Gateway (S-GW) features in Release 12.0. Additional information on these features can be found in the Cisco ASR 5000 Series Serving Gateway Administration Guide.
Previous behavior: Upon receiving RAT type, ULI, and MS timezone information from the MME for an additional PDN in a multi-PDN call, the S-GW would send this information on to the P-GW even if theses parameters had not changed. Also, if these parameters were only for one of the PDNs in a multi-PDN call, they were reported as the parameters for all the PDNs.
New behavior: The S-GW now forwards RAT type, ULI, and MS timezone only if there are changes to these parameters. If these parameters are only reported for one PDN in a multi-PDN call, they are only identified for the PDN for which they belong in the CDR.
The operator policy provides mechanisms to fine tune the behavior of subsets of subscribers above and beyond the behaviors described in the user profile. It also can be used to control the behavior of visiting subscribers in roaming scenarios, enforcing roaming agreements and providing a measure of local protection against foreign subscribers.
Circuit Switched Fall Back (CSFB) enables the UE to camp on an EUTRAN cell and originate or terminate voice calls through a forced switchover to the CS domain or other CS-domain services (e.g., Location Services (LCS) or supplementary services). Additionally, SMS delivery via the CS core network is realized without CSFB. Since LTE EPC networks were not meant to directly anchor CS connections, when any CS voice services are initiated, any PS based data activities on the EUTRAN network will be temporarily suspended (either the data transfer is suspended or the packet switched connection is handed over to the 2G/3G network).
While the primary responsibility of supporting CSFB fall to the MME, the S-GW supports CSFB messaging over the S11 interface.
IP Security (IPSec) on the S1-U and S5 interfaces is a node-to-node IKEv2 tunnel that can be configured to assume the characteristics of either a pre-configured tunnel or a dynamic tunnel.
Pre-configured node tunnels are fully qualified IPSec tunnels. Each IPSec tunnel is configured with parameters including pre-shared key, local and remote IP addresses, crypto hashes, groups, algorithms and the access control list (ACL).
Node-to-node dynamic tunnels are generated dynamically as the connections are initiated by different nodes in the LTE network. Each IPSec tunnel does not need to be pre-configured for each required parameter, instead it uses a common template for some parameters, like crypto algorithms, hashes, and groups. Other parameters are fetched dynamically from the tunnel requests like IP addresses and traffic selectors. Authentication information is fetched dynamically via certificates.
Typically, the eNodeB initiates an IPSec tunnel to the S-GW. The S-GW service is responsible to verify the configuration and use an IPSec API to make the S-GW listen on the service address for IKE requests.
When configured for IPSec, the S1-U interface carries subscriber data traffic and the S5 interface carries GTP-C signaling traffic and GTP-U data traffic that flows through an IPSec tunnel.
This section provides information on new Serving Gateway (S-GW) features in Release 12.2. Additional information on these features can be found in the Cisco ASR 5000 Series Serving Gateway Administration Guide.
A new configuration command is available to help calculate a timer that delays the sending of excess Downlink Data Notification messages by the S-GW to the MME in instances where downlink data is received before a Modify Bearer Request.
The S-GW now forwards Suspend/Resume messages towards the P-GW as an enhancement to the Circuit Switched Fallback (CSFB) feature in compliance with 3GPP Release 9.
The S-GW forwards Suspend Notification messages towards the P-GW to suspend downlink data for non-GBR traffic; the P-GW then drops all downlink packets. Later, when the UE finishes with CS services and moves back to E-UTRAN, the MME sends a Resume Notification message to the S-GW which forwards the message to the P-GW. The downlink data traffic then resumes.
CLI command added to enable/disable addition of the sequence number to every GTP-U packet coming from Gi interface and going towards Gn/Gp interface. If GTP-U packets are received out of sequence, sequence numbers would allow the packets to be reordered.
TCP Proxy support is now available for Lawful Intercept on the S-GW. Contact your local sales representative for detailed information.
The S-GW now supports the sending of a notification to LI administrators when an existing LI target provision has been modified or deleted. Contact your local sales representative for detailed information.
Location reporting can be used to support a variety of applications including emergency calls, lawful intercept, and charging. This feature reports both user location information (ULI) and user CSG information (UC)I.
The S-GW stores the ULI and UCI, and also reports the information to the accounting framework. This may lead to generation of Gz and Rf Interim records. The S-GW also forwards the received ULI and UCI to the P-GW. If the S-GW receives the UE time zone IE from the MME, it forwards this IE towards the P-GW across the S5/S8 interface.
Additionally, if the S-GW receives the UE timezone from S11/S4 interface, it now forwards this information to the P-GW.
The Diameter Rf interface supports offline charging (3GPP 32.240) for network services that are paid for periodically. For example, a user may have a subscription for voice calls that is paid monthly. The Rf protocol allows an IMS Charging Trigger Function (CTF) to issue offline charging events to a Charging Data Function (CDF). The charging events can either be one-time events or may be session-based.
The S-GW supports the enabling of this Diameter interface via operator policy. Options for accounting mode include: GTPP (default), RADIUS / Diameter or None.
This section provides information on new Serving GPRS Support Node (SGSN) features in Release 12.0. Additional information on these features can be found in the SGSN Release Notes available with the new releases, in the SGSN Administration Guide, and in the CLI Reference Guide.
The configuration limits have increased from 32 to 128 for the maximum number of LACs, as a combined total for LACs configured, for pool-areas and non-pool-areas for a Gs Service.
The software has been modified to more accurately segregate and represent 2G attach failure rates due to internal errors vs. procedure collisions. Multiple counters have been added, and some modified, to peg specific failures due to internal errors, and to peg failures due to ongoing procedure collisions, and counters added to log total attach failures due to internal errors.
The purpose and meaning of the ‘total-attach-failure’ counter has changed from being a combination of attach failures due to ongoing procedures and internal errors. Now the counter represents attach failures due only to internal errors.
The SGSN now fully supports regional subscription zone identities (RSZIs) in accordance with TS 23.008. The HLR stores a list of RSZIs; 10 per network destination code (NDC). The RSZI are comprised of the PLMN id and the zone code lists. The SGSN now enables the operator to define the zone code lists, to enable zone code checking, and to define the cause code for subscription rejection when it is due to regional subscription information failure.
The SGSN now supports the Network Requested PDP Context Activation (NRPCA) procedure for 3G attachments. Whenever there is downlink data at the GGSN for a subscriber, but there is no valid context for the already-established PDP address, the GGSN initiates an NRPCA procedure towards the SGSN. Prior to starting the NRPCA procedure, the GGSN either obtains the SGSN address from the HLR or uses the last SGSN address of the subscriber available at the GGSN. There are no interface changes to support this feature. Support is configured with existing CLI commands (network-initiated-pdp-activation, location-area-list) in the call-control-profile configuration mode and timers (T3385-timeout and max-actv-retransmission) are set in the SGSN service configuration mode.
Previous Behavior: The original APN remapping behavior was such that if any of the subscription record had matching charging characteristics then the requested APN would be remapped to the configured APN <apn_net_id>.
New Behavior: APN remapping behavior has been modified so that remapping occurs only when the charging characteristics value in the subscription record associated with the requested APN matches the configured value. This will avoid remapping of all APNs that the subscriber requests. This change is implemented with the new new-ni keyword of the cc command in the APN Remap Table configuration mode - explained in “Modified Commands” section of the Configuration chapter.
Previous Behavior: In the custom33 dictionary, the APN OI and NI were length encoded.
New Behavior: In the custom33 dictionary, the APN OI and NI are dot encoded.
For a PDP context request, an invalid APN occurs when none of the APNs in the HLR subscriber profile match the APN sent by the subscriber. The SGSN can now be provisioned to override an invalid APN even when a user has a wildcard APN in the HLR profile. The SGSN’s existing default APN functionality has been enhanced so that if a required subscription APN is not present in the subscriber profile, then the SGSN will now continue the activation with another configured 'dummy' APN. The call will be redirected, via the GGSN, to a Webpage informing the user of the error and prompting to subscribe for services.
Previously, if the required subscription APN was not present in subscriber profile, activation would be rejected.
The SGSN now provides the ability to configure default APN to be used in several different scenarios:
• Use the APN in the first subscription record as a default APN. With this option the first subscription record with matching PDP type and PDP address will be used as the default APN. Here, first record means the first among the records received from HLR in that order. The default APN will be used if normal APN selection fails. This function is enabled via the new key-word ‘first-in-subscription’.
• Fallback to the APN in the first subscription record when configured default APN is not available. It is possible to configure a default APN to be used. However, if the configured default APN is not present in subscription then the SGSN will use the APN in the first subscription record with matching PDP type and PDP address. This function is enabled via the new keyword ‘fallback-to-first-in-subscription’.
• Prefer to use a single subscription record option, which specifies that if normal APN selection fails and if there is only one subscription record, then use the APN in that subscription record as the default APN. This is an optional configuration and is specified along with a default APN to be used. The configured default APN will be used when there are more than one subscription records. This feature is enabled via the new keyword ‘prefer-single-subscription’.
Previous Behavior: The maximum number of APN profiles that could be associated with an operator policy was 50. The maximum number of IMEI ranges that could be associated with an operator policy was 10.
New Behavior: The maximum number of APN profiles that can be associated with an operator policy has increased from 50 to 128. The maximum number of IMEI ranges that can be associated with an operator policy has increased from 10 to 128 IMEI ranges.
It is now possible to append subscriber charging characteristic (SCHAR) information to the DNS string. The SGSN includes the profile index value portion of the CC as binary/decimal/hexadecimal digits (type based on the configuration) after the APN network identification. The charging characteristic value is taken from the subscription record selected for the subscriber during APN selection. This enables the SGSN to select a GGSN based on the charging characteristics information.
After appending the charging characteristic the DNS string will take the following form: <apn_network_id>.<profile_index>.<apn_operator_id >. The profile index in the following example has a value 10: quicknet.com.uk.1010.mnc234.mcc027.gprs.
If the RNC_ID information is configured to be a part of the APN name, and if inclusion of the profile index of the charging characteristics information is enabled (per this enhancement) before the DNS query is sent, then the profile index is included after the included RNC_ID and the DNS APN name will appear in the following form: <apn_network_id>.<rnc_id>.<profile_index>.<apn_op erator_id>. In the following example, the DNS query for a subscriber using RNC 0321 with the profile index of value 8 would appear as: quicknet.com.uk.0321.1000.mnc234.mcc027.gprs.
APN Selection of GGSN/PGW based on Network Capability - Behavioral Change - Demo Support
Previous Behavior: The SGSN could only select a GGSN (perform only DNS “A” queries).
New Behavior: The SGSN can also perform a DNS “SNAPTR” type (Straightforward Name Authority Pointer) query to select a PGW if the mobile UE is Release 9 compliant.
The Gn/Gp SGSN can now be configured to select a combined PGW/GGSN node to anchor a PDP context. During PDP context activation, after the APN is selected, normally a Gn/Gp SGSN does a DNS A/AAA query to resolve the APN into a GGSN IP address. Now, if the MS and the network are both EPC-capable, then the Gn/Gp SGSN should select a combined PGW/GGSN node to anchor the PDP context. This will enable the subscriber to roam into an EPC network without losing the PDP context.
In order to support PGW selection for an MS that is EPC capable, an SGSN shall do a DNS SNAPTR query for APN resolution.
If this feature is not enabled on the SGSN, the SGSN proceeds with the selection of a GGSN as usual, despite the UE ‘s network capability. Without this feature, whenever a release 9 compliant UE moves from a 2G/3G network to a 4G network, the PDP context has to be deactivated from the GGSN and a new activation towards a PGW is needed.
With this feature enabled, the signaling load on the network side is reduced because the deactivation and activation procedure is avoided when the SGSN selects a PGW during 2G/3G activation.
Default behavior has been changed to avoid PDP context deactivations resulting from GTP-C path failure detection due to messages containing erroneous restart counter change values.
Previous Behavior: The old default behavior was to have the SGSN detect GTP-C path failure based upon receiving restart counter changes in messages (Create PDP Context Response or Update PDP Context Response or Update PDP Context Request) from the GGSN and immediately begin PDP deactivation with a reactivation message. If the values in the messages are spurious, then this behavior could result in undesirable increases in network traffic due to bursts of deactivations/activations.
Ciphering Algorithm Negotiation Failure - Actions Configurable - Behavioral Change
Previously, if there was no match between the ciphering algorithm from the MS and the ciphering algorithm configured in either the call control profile or the GPRS service configuration, then the SGSN performed Attach or RAU without ciphering.
|
l
|
Reject an incoming Attach / RAU when there is not a match between the MS and SGSN configured ciphering algorithms. The call Attach/RAU Rejection message can include a configurable GMM failure code.
|
It is now possible for the operator to configure a reduced priority for LinkManager Control messages, thereby giving timer messages the highest priority. The timer messages are retained at the highest priority and data messages are kept at a lower priority. As a part of this enhancement, a new parameter, sctp-init-rwnd, will enable the SCTP association to maintain a configurable window at the receiving end.
To avoid high traffic levels during PDP establishment, the SGSN has been modified to reduce the attach time, as much as possible, so that the devices can attach and discontinue sending requests. This change is intended to reduce the time needed to retrieve vectors over the Gr interface by allowing the operator to configure the SGSN to start authentication towards the MS as soon as it receives the first vector from the AuC/HLR. With the change to the configuration, the SGSN begins the MS authentication process immediately after receiving the first vector from the HLR, while the SAI continues in parallel.
The attach process may continue in the case of an IMEI check timeout, based on the SGSN service and/or the GPRS service configuration. But the attach only proceeds if the route towards the EIR is up and the IMEI request timer expires.
The software has been enhanced to configure the SGSN to allow the attach process to continue if the route towards the EIR is down, e.g., the DPC / SSN is out of service. This new CLI control command has been added to SGSN service and GPRS service configuration modes.
The SGSN’s local QoS THP and ARP configurations can now override the QoS traffic handling priority (THP) value and allocation/retention priority (ARP) from an HLR subscription. This QoS capping can be done on a per-APN basis and is configurable in the APN profile for use through the operator policy function.
This functionality can differentiate home vs. roaming subscribers, and prevent visiting subscribers from receiving a high-tiered service. For example, a service provider could offer service differentiation using Ultra/Super/Standard service levels based upon QoS; this could justify charging a corporate customer more to use the Internet APN than would be charged to a consumer. This could be accomplished by controlling the traffic handling priority (THP) over the air interface, i.e. THP 1 = Ultra, THP 2 = Super and THP 3 = Standard. But this must be configured at the operator policy level to prevent a “roamed-in” customer from getting Ultra service if the foreign subscriber’s network provisions all of their customers with THP 1 on their HLRs.
A new custom33 dictionary is available. It is compliant with 3GPP TS 32.298 v.6.4.1 (custom6) with the following exceptions:
The SGSN now supports both IPv4 or IPv6 formats for the PDP IP address field in the S-CDR using the custom33 dictionary.
Checking access restriction data (ARD) in incoming insert subscriber data (ISD) messages is particularly useful in selectively restricting a subscriber in either 3G (UTRAN) or 2G (GERAN). In a previous release, the SGSN default behavior for an attach procedure was changed to check the ARD in the ISD and then accept or reject the subscriber with a configurable cause code included in the reject message.
To facilitate monitoring and troubleshooting of Gb/FR E1/T1 connections, new CLI output counters have been added to measure the current and high/low watermark counters. As well, a new bulk statistics schema has been added, DLCI-Util, to monitor DLCI utilization thresholds.
Previous Behavior: The option to enable DNS SNAPTR for 3G subscribers with EPC subscription was under SGSN Global configuration.
New Behavior: The CLI to enable DNS SNAPTR for 3G subscribers with EPC subscription has been moved to APN Profile configuration. This will enable control of this feature per APN.
IMPORTANT: Impact on Customer: CLI configuration change required.The SGSN now supports diffserv code point (DSCP) marking of the GTP control plane messages on the Gn/Gp interface. This allows QoS to be set on GTP-C messages, and is useful if Gn/Gp is on a less than ideal link. DSCP marking is configurable via the CLI, with default = Best Effort Forwarding.
New configuration commands were added to create or remove a DSCP template which provides configuration of DSCP values for both control packets and data packets of different classes for traffic on Gb over IP.
The CLI commands which create or remove the DSCP templates are done at an SGSN-global level under the SGSN Global configuration mode; which also provides access to the new DSCP Template configuration mode.
These templates are associated with any of the configured GPRS services which allows that service to apply the configured DSCP values for all downlink packets sent out from the SGSN. If there is no profile associated with the GPRS service, the SGSN uses the default “Best Effort” DSCP values for both control and data packets.
The SGSN now fully supports empty SCCP Connection Requests and now adds the ability to process intra-RAU/ Detach/Service Request messages after empty CRs.
The SCCP CR messages contain the RNC’s local reference for the particular connection at the SCCP level but not any RANAP payload. Typically, the SCCP CRs will have a max payload of 130 octets with the RANAP-Initial-UE message from the RNC as the only RANAP message in the CR. The payload of the RANAP-Initial-UE can be one of the following:
In situations where the payload exceeds 130 octets, the RNC may send an empty CR followed by the direct-transfer 1 (DT1) message with the actual payload.
The grouping configuration ranges for T1 and E1 channels has been enhanced. The SGSN now supports the full 0-31 timeslots for Frame Relay (channelized) port configuration, 32 for E1 and 24 for T1.
Previously, the SGSN allowed Gb/Iu Flex subscriber offloading only as per the specification-defined NULL NRI in P-TMSI and Non-Broadcast LAC/RAC mechanism. However, not all RNCs and BSSs support NULL-NRI.
The SGSN now supports Gb/Iu Flex subscriber offloading from one SGSN to another specific SGSN in a 2G/3G pool. In addition, the operator can configure the offloading Target NRI in P-TMSI, and the quantity to off load to the Target. This can be used to provide load balancing, or to off load a single node in pool, take it out of service for whatever reason (e.g., maintenance).
To facilitate troubleshooting, the SGSN will capture procedure-level information per 2G or 3G subscriber (IMSI-based) in CSV formatted event data records (EDRs) that are stored on an external server. This feature logs the following events:
The SGSN can now measure the control plane packet delay for GTP-C signaling messages on the SGSN’s Gn/Gp interface towards the GGSN. If the delay crosses a configurable threshold, an alarm will be generated to prompt the operator.
A delay trap is generated when the GGSN response to an ECHO message request is delayed more than a configured amount of time and for a configured number of consecutive responses. When this occurs, the GGSN will be flagged as experiencing delay.
A clear delay trap is generated when successive ECHO Response (number of successive responses to detect a delay clearance is configurable), are received from a GGSN previously flagged as experiencing delay.
By default, the SGSN updates the CAMEL subscription included in the INSERT-SUBSCRIBER-DATA (ISD) messages received from the HLR. While processing the ATTACH request from the CAMEL subscriber, the SGSN checks whether it has a CAMEL service associated with the corresponding service (either GPRS service or SGN service). It drops the ATTACH request if there is no CAMEL service associated with a corresponding service.
Also by default, the SGSN does not allow establishment of a Direct Tunnel (DT) for a CAMEL subscriber. It strictly validates the subscriber against the CAMEL subscription during the Direct Tunnel setup procedure.
This enhancement makes it possible to control the behavior of the SGSN by configuring the SGSN to ignore the CAMEL subscription. This allows the SGSN to successfully complete an ATTACH procedure when there is an ATTACH Request from a CAMEL subscriber and there is no CAMEL service association in the SGSN. As well, during the Direct Tunnel establishment, validation of the CAMEL subscription is ignored to allow the DT to setup when there is no CAMEL service association in the SGSN.
It is now possible to configure the SGSN to allow only one subscriber, at a time, to attach using a fixed random TLLI. While an Attach procedure with a fixed random TLLI is ongoing (that is, until a new P-TMSI is accepted by the MS), all other attaches sent to the SGSN with the same random TLLI, but using a different IMSI, will be dropped by the SGSN’s Linkmgr.
A configurable timer has been implemented on the SGSN (invalidate old-TLLI timer) which will start upon the receipt of an Attach-Complete message with an old random TLLI. This timer will stop once an uplink packet (e.g., an Activation Request message) is received from the attached subscriber with the TLLI allocated by the SGSN. If no uplink packet is received by the subscriber with the TLLI allocated within the configured time (wait-time), the random TLLI mapping with that IMSI is freed and any other Attach Request with the same fixed random TLLI is accepted. No further attaches from the configured fixed-random TLLI are accepted until the timer is either stopped or has expired. In addition, to limit the wait-time functionality to only the fixed random TLLI subscribers, the TLLI list can be configured to control which subscribers will be provided his functionality.
LAG works by exchanging control packets (Link Aggregation Control Marker Protocol) over configured physical ports with peers to reach agreement on an aggregation of links. LAG sends and receives the control packets directly on physical ports attached to different XGLCs.
The link aggregation feature provides higher aggregated bandwidth, auto-negotiation, and recovery when a member port link goes down.
On receiving RANAP messages from the RNC, the SGSN could experience a problem with PDP context establishment if the message is too long. Following a successful Attach, if the SGSN received a SCCP Connection Request with a GMM Service Request message from the RNC, the SGSN might respond with a SCCP Connection Refused for no clear reason. Further investigation revealed that at the RANAP layer the messages contained an Extension item, a Redirect Attempt Flag, and the SGSN reported a decode error while processing this additional octet.
For a PDP context request, an invalid APN occurs when none of the APNs in the HLR subscriber profile match the APN sent by the subscriber. The SGSN can now be provisioned to override an invalid APN even when a user has a wildcard APN in the HLR profile. The SGSN’s existing default APN functionality has been enhanced so that if a required subscription APN is not present in the subscriber profile, then the SGSN will now continue the activation with another configured 'dummy' APN. The call will be redirected, via the GGSN, to a Webpage informing the user of the error and prompting to subscribe for services.
Previously, if the required subscription APN was not present in subscriber profile, activation would be rejected.
The Lawful Intercept buffering feature has been enhanced to increase the number of call content records that can be buffered (or held in the buffer). For details, contact your local Cisco sales representative.
Previously, the SGSN supported GGSN selection for an APN only through operator policy, and supported a single pool of up to 16 GGSN addresses which were selected in round robin fashion.
The SGSN now supports configuration of multiple pools of GGSNs. As part of DNS resolution, the operator can use operator policies to prioritize local GGSNs versus remote ones. This function is built upon existing load balancing algorithms in which weight and priority are configured per GGSN. With the multiple GGSN pools feature, at this time, only the weight algorithm is used for selection. So with the primary GGSN pool used first and the secondary pool used when no primary GGSNs are available.
The SGSN first selects a primary pool and then GGSNs within that primary pool; employing a round robin mechanism for selection. If none of the GGSNs in a pool are available for activation, then the SGSN proceeds with activation selecting a GGSN from a secondary pool on the basis of assigned weight. A GGSN is considered unavailable when it does not respond to GTP Requests after a configurable number of retries over a configurable time period. Path failure is detected via GTP-echo.
The SGSN now provides the ability to map a maximum bit rate (MBR) value (provided by the HLR) to an HSPA MBR value. The mapped value is selected based on the matching MBR value obtained from the HLR subscription. QoS negotiation then occurs based on the converted value.
This feature is available within the operator policy framework. MBR mapping is configured via new keywords added to the qos class command in the APN Profile configuration mode. A maximum of four values can be mapped per QoS per APN. For details, refer to CSCzn32233 in the CLI Syntax section of the Interface Changes section of this release note.
NOTE: To enable this feature the qos prefer-as-cap, also a command in the APN Profile configuration mode, must be set to either both-hlr-and-local or to hlr subscription.
Refer to SGSN Modified Commands in the Configuration chapter of this document and to the Cisco ASR 5000 Series Command Line Interface Reference for details of the changes to the CLI.
Managing Path Failure Detection due to Restart Counter Change - Behavioral Change
The SGSN now provides the ability to manage GTP-C path failures detected as a result of spurious restart counter change messages received from the GGSN.
When the SGSN detects GTP-C path failure between the SGSN and the GGSN, the SGSN now assumes PDP sessions at the GGSN are lost and the SGSN deactivates those PDP sessions towards the UE with an indication that the UE should activate the PDP session again. Detection is based on receipt of restart counter change values in messages (Create PDP Context Response or Update PDP Context Response or Update PDP Context Request) which can be spurious. Potentially, this scenario can increase traffic within the operator’s network.
Various enhancements have been made to manage the resulting service deactivations and activations which would cause needlessly large bursts of network traffic if the restart counter change messages from the GGSN are erroneous:
|
l
|
New default behavior defined for handling GTP-C path failures detected as a result of erroneous restart counter changes received from the GGSN. See details in the Operator Notes.
|
Previously, the following parameters were available for configuration and for statistics display when the SS7 link was configured for low-speed:
Previously, the following parameters were available for configuration and for statistics display when the SS7 link was configured for high-speed:
In accordance with specification Q.703, now EIM parameters are only available when SS7 link is configured for high-speed and AERM/SUERM parameters are only available when SS7 link is configured for low-speed.
The SGSN is performing trials for support of S3/S4 interfaces to enable simultaneous access between 2G and 3G networks and LTE networks with MME and S-GW.
Now with this feature the operator can include the RNC_ID information with the name of the APN before the query is sent to the DNS. This feature makes it possible to select a GGSN based on the RNC_ID. Name format example: <apn_name>.<rnc_id>.<mncxxx>.<mccyyy>.gprs
With the RNC_ID inclusion enabled, the operator can also include the SCHAR (charging characteristic information) so that both the SCHAR and the RNC_ID information would be added to the name of the APN before the query is sent to the DNS. Name format example: <apn_name>.<rnc_id>.<schar>.<mncxxx>.<mccyyy>.gprs.
It is now possible to configure the SGSN to append LAC and RAC info to an APN DNS query for GGSN selection. It is expected that the DNS will use this information to determine the GGSN to route the APN.
For example, roaming subscribers using a specific APN may want to be directed to the closest GGSN. This can be achieved by having an operator policy for roaming subscribers associated with an APN profile that includes a configuration specifying that geographical information from the LAC/RAC be appended to the APN. This is then used as the DNS query string but does not modify the APN string being sent to the GGSN.
Previous Behavior: In earlier releases, the dictionaries used by the S-CDRs included but did not implement the Network Initiated PDP Context field, hence the field was not populated.
New Behavior: Now, all the SGSN’s 3GPP compliant dictionaries implement this field and the field will be populated in the following dictionaries: custom6, custom8, custom13, custom24. This field will be populated if the PDP context is activated by the network side or if the customer is enabling a RAU from LTE to 3G.
The SGSN’s optimized network overload protection performs attach-rate throttling to avoid overloading Gr, Gn and Gf interfaces. When enabled, the IMSIMgr throttles the attach rate to a value configured with a new set of queue-size and wait-time keywords.
If the SGSN receives more than the configured number of attaches in a second, then the attaches are buffered in the pacing queue and requests are only dropped when the buffer overflows due to high incoming attach rate. Messages in the queue are processed (FIFO) until they age-out when the queued message's lifetime crosses the configured wait-time. The wait-time and the attach rate decide the optimal size of the queue.
The GMM-SM event logging feature has been enhanced so that the EDR print format is no longer fixed in length. The length is now variable. So, if the MNC has 2 digits then the RAI or OLD-RAI print format does not append a zero “0” which could cause an MNC error. During the GMM-SM event logging, the RAI and OLD-RAI fields in the EDR now have a variable length depending on the number of digits in the MNC. Based on the MNC, the length can now be 15 (xxx-xxx-xxxx-xx) or 14 (xxx-xx-xxxx-xx) characters. For example, if MNC has 2 digits “09” then the RAI or OLD_RAI prints as - xxx-09-xxxx-xx.
The SGSN now supports the PSC3 with PSC2-level capacity. This means the PSC3 in an SGSN currently supports the same number of subscribers as the SGSN with PSC2 cards. No special configuration is required.
The Cisco SGSN now supports Packet Temporary Mobile Subscriber Identity (P-TMSI) signature reallocation for all types of routing area update (RAU) events.
The P-TMSI is a temporary identity issued to a GPRS enabled mobile, unique within a given RA (routing area), and is used by the GPRS network to page the specified mobile. When enabled, the SGSN sends a P-TMSI signature to the MS in an RAU Accept message, and the MS must include the P-TMSI Signature in the next RAU request for the SGSN to compare with the original signature.
You can now configure the frequency and interval of P-TMSI signature reallocation for Periodic RAU and Normal RAU events. In this way, the SGSN can change the P-TMSI assigned to the MS as often as needed to maintain confidentiality of an MS when roaming.
When enabled, this feature allows the SGSN to send the Attach Reject for the Attach Request received with a P-TMSI signature mismatch message. This is done, primarily, to avoid the identification of incorrect mapping of P-TMSI/IMSI at the SGSN if the P-TMSI was allocated to a different MS. Enabling this feature allows the SGSN to validate the PTMSI signature present in the Attach Request against the PTMSI-SIGNATURE stored in the SGSN and then the SGSN sends the Attach Reject to the MS if the P-TMSI signature does not match.
This is applicable only for 2G attaches and this configuration forces the operator to enable P-TMSI reallocation during Attach and INTER-SGSN-RAU procedures.
The “default” and “no” keywords in the qos class command (APN Profile configuration mode) have been replaced resulting in the following behavioral changes:
Prior to release 12, using the “default” keyword in the qos class command resulted in only a few QoS class parameters being set to predefined values and “default” was not applicable to an entire QoS class. As well, using the “no” keyword invalidated the local configuration for the entire class identified in the command.
New behavior in release 12: The new “all-values” keyword configures predefined values for all the QoS parameters within a QoS class when the keyword is invoked. Until then, there are no values configured for QoS parameters, primarily to ensure that when the QoS preference is set to “both-hlr-and-local” (since the least of the HLR and local values is considered), the SGSN does not always select the locally predefined values as they often are the lowest possible values for these parameters. This change provides a simple method to specify that all the parameters of a given QoS class, or simply to an individual, specified QoS parameter, be assigned some predefined values. The new “remove” keyword deletes the configured value(s) for an individual QoS parameter or for all parameters for a specified QoS class.
RAI is no longer included automatically. Inclusion is operator configurable and for the following list of message types:
|
l
|
|
l
|
In previous releases, the SGSN partially supported reordering out-of-order segments coming from the same SNDCP N-PDU. If the first N-PDU segment came after subsequent segments, then the entire N-PDU was dropped.
Now, the SGSN fully supports reordering out-of-order segments coming from the same SNDCP N-PDU. The SGSN waits the configured amount of time for all segments of the N-PDU to arrive. If all the segments are not received before the timer expiries, then all queued segments are dropped.
Previous Behavior: Previously, there was no QoS capping for R7 RNC and capping was set at 16 mbps for all pre-R7 RNC. Bit rate override was not available.
New Behavior: Now, bit rate override is configurable per RNC. For cap rate information, refer to the release-compliance command information in the Command Line Interface Reference.
The SGSN is trailing support for the S6d interface between the SGSN and the HSS. This will enable the SGSN to get subscription details of a 4G user from the HSS when user tries to register with the SGSN, either as part of an Inter-RAT handoff from 4G, or while attaching into 3G or 2G access.
The SGSN now allows settings to be configured with finer granularity for several of the SCTP timers:
For syntax details, refer to CSCzn15895 (130556) / CSCzn16886 (131704) in the Interface Changes section.
Previously, the SGSN provides an authentication procedures for standard GMM events like Attach, Detach, RAU, and Service-Request, and SMS events such as Activate, all with support for 1-in-N Authenticate functionality. The SGSN did not provide the capability to authenticate MO/MT SMS events.
Now, the authentication functionality has been expanded to the Gs interface where the SGSN now supports configuration of the authentication repetition rate for SMS-MO and SMS-MT, for every nth event. This functionality is built on existing SMS CLI, with configurable MO and/or MT. The default is not to authenticate.
Previously, the SGSN supported restricting MO-SMS and MT-SMS only through SGSN operator policy configuration.
Now, the SGSN can restrict forwarding of SMS messages to specific SMSC addresses, in order to allow operators to block SMS traffic that cannot be charged for. This functionality supports multiple SMSCs and is configurable per SMSC address with a maximum of 10 addresses. It is also configurable for MO-SMS and/or MT-SMS messages.
Automatic Protection Switching (APS) is the ability of the system to detect failures on a working facility and switch to a designated backup facility. The failures are detected in the Multiplex Section of the SDH Overhead (MSOH) or Section Overhead (SOH) of SONET.
The SGSN now provides inter-card support of SONET APS and MSP (Multiplexed Switching Protection) functionality on the Optical Line Card 2 (OLC2) as specified in G.783 Annex A.
Previous Behavior: The SGSN believed the UE could be classified as supporting or non-supporting only during Attach.
New Behavior: Now, the SGSN classifies the UE as supporting or non-supporting UE for either Attach or RAU.
The software has been enhanced to allow the operator to configure a threshold indicating the minimum number of unused vectors that should be maintained by the SGSN before it initiates a SAI to refill the buffer. With this feature enabled, the SGSN will maintain a specific number of unused vectors at all times. The SAI is initiated when a vector is used up by the SGSN for authentication and the configuration threshold is hit. The SAI initiated, due to this configuration, will be ongoing in parallel to the procedures. This feature changes how many vectors are retrieved from the HLR each time and stored on the SGSN so it should increase performance by decreasing the amount of interaction with the HLR during procedures.
Previous Behavior: The SGSN was not generating traps if Reset-ACK was not received from the RNC. The SGSN was logging not having received a Reset-ACK.
New Behavior: Now, upon expiry of all retransmission timers for reset from the SGSN, the SGSN will generate a visible trap and make a log entry when Reset-ACK is not received. The new trap is of type Notification, so there is no clear trap operation required.
New counters have been added for 2G Modify PDP Abort and for 3G Modify Abort. The new counters facilitate verification of the EDR GMM-SM event logs.
This section provides information on new Serving GPRS Support Node (SGSN) features in Release 12.1. Additional information on these features can be found in the SGSN Administration Guide, and in the CLI Reference Guide.
The configuration limits have increased from 32 to 128 for the maximum number of LACs, as a combined total for LACs configured, for pool-areas and non-pool-areas for a Gs Service.
The SGSN now fully supports regional subscription zone identities (RSZIs) in accordance with TS 23.008. The HLR stores a list of RSZIs; 10 per network destination code (NDC). The RSZI are comprised of the PLMN id and the zone code lists. The SGSN now enables the operator to define the zone code lists, to enable zone code checking, and to define the cause code for subscription rejection when it is due to regional subscription information failure.
The SGSN now supports the Network Requested PDP Context Activation (NRPCA) procedure for 3G attachments. Whenever there is downlink data at the GGSN for a subscriber, but there is no valid context for the already-established PDP address, the GGSN initiates an NRPCA procedure towards the SGSN. Prior to starting the NRPCA procedure, the GGSN either obtains the SGSN address from the HLR or uses the last SGSN address of the subscriber available at the GGSN. There are no interface changes to support this feature. Support is configured with existing CLI commands (network-initiated-pdp-activation, location-area-list) in the call-control-profile configuration mode and timers (T3385-timeout and max-actv-retransmission) are set in the SGSN service configuration mode.
For a PDP context request, an invalid APN occurs when none of the APNs in the HLR subscriber profile match the APN sent by the subscriber. The SGSN can now be provisioned to override an invalid APN even when a user has a wildcard APN in the HLR profile. The SGSN’s existing default APN functionality has been enhanced so that if a required subscription APN is not present in the subscriber profile, then the SGSN will now continue the activation with another configured 'dummy' APN. The call will be redirected, via the GGSN, to a Webpage informing the user of the error and prompting to subscribe for services.
Previously, if the required subscription APN was not present in subscriber profile, activation would be rejected.
The SGSN now provides the ability to configure default APN to be used in several different scenarios:
• Use the APN in the first subscription record as a default APN. With this option the first subscription record with matching PDP type and PDP address will be used as the default APN. Here, first record means the first among the records received from HLR in that order. The default APN will be used if normal APN selection fails. This function is enabled via the new key-word ‘first-in-subscription’.
• Fallback to the APN in the first subscription record when configured default APN is not available. It is possible to configure a default APN to be used. However, if the configured default APN is not present in subscription then the SGSN will use the APN in the first subscription record with matching PDP type and PDP address. This function is enabled via the new keyword ‘fallback-to-first-in-subscription’.
• Prefer to use a single subscription record option, which specifies that if normal APN selection fails and if there is only one subscription record, then use the APN in that subscription record as the default APN. This is an optional configuration and is specified along with a default APN to be used. The configured default APN will be used when there are more than one subscription records. This feature is enabled via the new keyword ‘prefer-single-subscription’.
The SGSN’s local QoS THP and ARP configurations can now override the QoS traffic handling priority (THP) value and allocation/retention priority (ARP) from an HLR subscription. This QoS capping can be done on a per-APN basis and is configurable in the APN profile for use through the operator policy function.
This functionality can differentiate home vs. roaming subscribers, and prevent visiting subscribers from receiving a high-tiered service. For example, a service provider could offer service differentiation using Ultra/Super/Standard service levels based upon QoS; this could justify charging a corporate customer more to use the Internet APN than would be charged to a consumer. This could be accomplished by controlling the traffic handling priority (THP) over the air interface, i.e. THP 1 = Ultra, THP 2 = Super and THP 3 = Standard. But this must be configured at the operator policy level to prevent a “roamed-in” customer from getting Ultra service if the foreign subscriber’s network provisions all of their customers with THP 1 on their HLRs.
A new custom33 dictionary is available. It is compliant with 3GPP TS 32.298 v.6.4.1 (custom6) with the following exceptions:
Checking access restriction data (ARD) in incoming insert subscriber data (ISD) messages is particularly useful in selectively restricting a subscriber in either 3G (UTRAN) or 2G (GERAN). In a previous release, the SGSN default behavior for an attach procedure was changed to check the ARD in the ISD and then accept or reject the subscriber with a configurable cause code included in the reject message.
The SGSN now supports diffserv code point (DSCP) marking of the GTP control plane messages on the Gn/Gp interface. This allows QoS to be set on GTP-C messages, and is useful if Gn/Gp is on a less than ideal link. DSCP marking is configurable via the CLI, with default = Best Effort Forwarding.
The grouping configuration ranges for T1 and E1 channels has been enhanced. The SGSN now supports the full 0-31 timeslots for Frame Relay (channelized) port configuration, 32 for E1 and 24 for T1.
Previously, the SGSN allowed Gb/Iu Flex subscriber offloading only as per the specification-defined NULL NRI in P-TMSI and Non-Broadcast LAC/RAC mechanism. However, not all RNCs and BSSs support NULL-NRI.
The SGSN now supports Gb/Iu Flex subscriber offloading from one SGSN to another specific SGSN in a 2G/3G pool. In addition, the operator can configure the offloading Target NRI in P-TMSI, and the quantity to off load to the Target. This can be used to provide load balancing, or to off load a single node in pool, take it out of service for whatever reason (e.g., maintenance).
The SGSN can now measure the control plane packet delay for GTP-C signaling messages on the SGSN’s Gn/Gp interface towards the GGSN. If the delay crosses a configurable threshold, an alarm will be generated to prompt the operator.
A delay trap is generated when the GGSN response to an ECHO message request is delayed more than a configured amount of time and for a configured number of consecutive responses. When this occurs, the GGSN will be flagged as experiencing delay.
A clear delay trap is generated when successive ECHO Response (number of successive responses to detect a delay clearance is configurable), are received from a GGSN previously flagged as experiencing delay.
The SGSN now supports enhanced link aggregation (LAG) within ports on different side-by-side XGLCs. Ports can be from multiple XGLCs with some cards in L2 (side-by-side) redundancy.
LAG works by exchanging control packets (Link Aggregation Control Marker Protocol) over configured physical ports with peers to reach agreement on an aggregation of links. LAG sends and receives the control packets directly on physical ports attached to different XGLCs.
The link aggregation feature provides higher aggregated bandwidth, auto-negotiation, and recovery when a member port link goes down. With side-by-side redundancy on the XGLC, link aggregation supports horizontal ports from both XGLC cards.
For a PDP context request, an invalid APN occurs when none of the APNs in the HLR subscriber profile match the APN sent by the subscriber. The SGSN can now be provisioned to override an invalid APN even when a user has a wildcard APN in the HLR profile. The SGSN’s existing default APN functionality has been enhanced so that if a required subscription APN is not present in the subscriber profile, then the SGSN will now continue the activation with another configured 'dummy' APN. The call will be redirected, via the GGSN, to a Webpage informing the user of the error and prompting to subscribe for services.
Previously, if the required subscription APN was not present in subscriber profile, activation would be rejected.
The Lawful Intercept buffering feature has been enhanced to increase the number of call content records that can be buffered (or held in the buffer). For details, refer to the ASR 5000 Series Lawful Intercept Configuration Guide.
Previously, the SGSN supported GGSN selection for an APN only through operator policy, and supported a single pool of up to 16 GGSN addresses which were selected in round robin fashion.
The SGSN now supports configuration of multiple pools of GGSNs. As part of DNS resolution, the operator can use operator policies to prioritize local GGSNs versus remote ones. This function is built upon existing load balancing algorithms in which weight and priority are configured per GGSN. With the multiple GGSN pools feature, at this time, only the weight algorithm is used for selection. So with the primary GGSN pool used first and the secondary pool used when no primary GGSNs are available.
The SGSN first selects a primary pool and then GGSNs within that primary pool; employing a round robin mechanism for selection. If none of the GGSNs in a pool are available for activation, then the SGSN proceeds with activation selecting a GGSN from a secondary pool on the basis of assigned weight. A GGSN is considered unavailable when it does not respond to GTP Requests after a configurable number of retries over a configurable time period. Path failure is detected via GTP-echo.
The SGSN now provides the ability to map a maximum bit rate (MBR) value (provided by the HLR) to an HSPA MBR value. The mapped value is selected based on the matching MBR value obtained from the HLR subscription. QoS negotiation then occurs based on the converted value.
This feature is available within the operator policy framework. MBR mapping is configured via new keywords added to the qos class command in the APN Profile configuration mode. A maximum of four values can be mapped per QoS per APN. For details, refer to CSCzn32233 in the CLI Syntax section of the Interface Changes section of this release note.
NOTE: To enable this feature the qos prefer-as-cap, also a command in the APN Profile configuration mode, must be set to either both-hlr-and-local or to hlr subscription.
Refer to SGSN Modified Commands in the Configuration chapter of this document and to the Cisco ASR 5000 Series Command Line Interface Reference for details of the changes to the CLI.
Previously, the following parameters were available for configuration and for statistics display when the SS7 link was configured for low-speed:
Previously, the following parameters were available for configuration and for statistics display when the SS7 link was configured for high-speed:
In accordance with specification Q.703, now EIM parameters are only available when SS7 link is configured for high-speed and AERM/SUERM parameters are only available when SS7 link is configured for low-speed.
The SGSN is performing trials for support of S3/S4 interfaces to enable simultaneous access between 2G and 3G networks and LTE networks with MME and S-GW.
The SGSN now supports the PSC3 with PSC2-level capacity. This means the PSC3 in an SGSN currently supports the same number of subscribers as the SGSN with PSC2 cards. No special configuration is required.
The Cisco SGSN now supports Packet Temporary Mobile Subscriber Identity (P-TMSI) signature reallocation for all types of routing area update (RAU) events.
The P-TMSI is a temporary identity issued to a GPRS enabled mobile, unique within a given RA (routing area), and is used by the GPRS network to page the specified mobile. When enabled, the SGSN sends a P-TMSI signature to the MS in an RAU Accept message, and the MS must include the P-TMSI Signature in the next RAU request for the SGSN to compare with the original signature.
You can now configure the frequency and interval of P-TMSI signature reallocation for Periodic RAU and Normal RAU events. In this way, the SGSN can change the P-TMSI assigned to the MS as often as needed to maintain confidentiality of an MS when roaming.
The “default” and “no” keywords in the qos class command (APN Profile configuration mode) have been replaced resulting in the following behavioral changes:
Prior to release 12, using the “default” keyword in the qos class command resulted in only a few QoS class parameters being set to predefined values and “default” was not applicable to an entire QoS class. As well, using the “no” keyword invalidated the local configuration for the entire class identified in the command.
New behavior in release 12: The new “all-values” keyword configures predefined values for all the QoS parameters within a QoS class when the keyword is invoked. Until then, there are no values configured for QoS parameters, primarily to ensure that when the QoS preference is set to “both-hlr-and-local” (since the least of the HLR and local values is considered), the SGSN does not always select the locally predefined values as they often are the lowest possible values for these parameters. This change provides a simple method to specify that all the parameters of a given QoS class, or simply to an individual, specified QoS parameter, be assigned some predefined values. The new “remove” keyword deletes the configured value(s) for an individual QoS parameter or for all parameters for a specified QoS class.
RAI is no longer included automatically. Inclusion is operator configurable and for the following list of message types:
|
l
|
|
l
|
In previous releases, the SGSN partially supported reordering out-of-order segments coming from the same SNDCP N-PDU. If the first N-PDU segment came after subsequent segments, then the entire N-PDU was dropped.
Now, the SGSN fully supports reordering out-of-order segments coming from the same SNDCP N-PDU. The SGSN waits the configured amount of time for all segments of the N-PDU to arrive. If all the segments are not received before the timer expiries, then all queued segments are dropped.
The SGSN is trailing support for the S6d interface between the SGSN and the HSS. This will enable the SGSN to get subscription details of a 4G user from the HSS when user tries to register with the SGSN, either as part of an Inter-RAT handoff from 4G, or while attaching into 3G or 2G access.
The SGSN now allows settings to be configured with finer granularity for several of the SCTP timers:
For syntax details, refer to CSCzn15895 (130556) / CSCzn16886 (131704) in the Interface Changes section.
Previously, the SGSN provides an authentication procedures for standard GMM events like Attach, Detach, RAU, and Service-Request, and SMS events such as Activate, all with support for 1-in-N Authenticate functionality. The SGSN did not provide the capability to authenticate MO/MT SMS events.
Now, the authentication functionality has been expanded to the Gs interface where the SGSN now supports configuration of the authentication repetition rate for SMS-MO and SMS-MT, for every nth event. This functionality is built on existing SMS CLI, with configurable MO and/or MT. The default is not to authenticate.
Previously, the SGSN supported restricting MO-SMS and MT-SMS only through SGSN operator policy configuration.
Now, the SGSN can restrict forwarding of SMS messages to specific SMSC addresses, in order to allow operators to block SMS traffic that cannot be charged for. This functionality supports multiple SMSCs and is configurable per SMSC address with a maximum of 10 addresses. It is also configurable for MO-SMS and/or MT-SMS messages.
Automatic Protection Switching (APS) is the ability of the system to detect failures on a working facility and switch to a designated backup facility. The failures are detected in the Multiplex Section of the SDH Overhead (MSOH) or Section Overhead (SOH) of SONET.
The SGSN now provides inter-card support of SONET APS and MSP (Multiplexed Switching Protection) functionality on the Optical Line Card 2 (OLC2) as specified in G.783 Annex A.
This section provides information on new Serving GPRS Support Node (SGSN) features in Release 12.2. Additional information on these features can be found in the SGSN Administration Guide, and in the CLI Reference Guide.
Previous Behavior: The original APN remapping behavior was such that if any of the subscription record had matching charging characteristics then the requested APN would be remapped to the configured APN <apn_net_id>.
New Behavior: APN remapping behavior has been modified so that remapping occurs only when the charging characteristics value in the subscription record associated with the requested APN matches the configured value. This will avoid remapping of all APNs that the subscriber requests. This change is implemented with the new new-ni keyword of the cc command in the APN Remap Table configuration mode - explained in “Modified Commands” section of the Configuration chapter.
Previous Behavior: When a BVC was mapped to a specific cell-ID and the SGSN received a BVC Reset with a different cell-ID, then a new entry was added in the mapping for the new BVCI but the old mapping entry was not deleted. The BVCI of the subscriber was not updated until the SGSN received the next uplink packet from the MS.
New Behavior: The SGSN maintains BVC to cell-ID mapping. When a BVC is mapped to a specific cell-ID and the SGSN receives a BVC Reset with a different cell-ID, then a new entry is added in the mapping for the new BVCI. The BVCI of the subscriber is updated and the old mapping entry is deleted.
APN Selection of GGSN/PGW based on Network Capability - Behavioral Change
Previous Behavior: The SGSN could only select a GGSN (perform only DNS “A” queries).
New Behavior: The SGSN can also perform a DNS “SNAPTR” type (Straightforward Name Authority Pointer) query to select a PGW if the mobile UE is Release 9 compliant.
The Gn/Gp SGSN can now be configured to select a combined PGW/GGSN node to anchor a PDP context. During PDP context activation, after the APN is selected, normally a Gn/Gp SGSN does a DNS A/AAA query to resolve the APN into a GGSN IP address. Now, if the MS and the network are both EPC-capable, then the Gn/Gp SGSN should select a combined PGW/GGSN node to anchor the PDP context. This will enable the subscriber to roam into an EPC network without losing the PDP context.
In order to support PGW selection for an MS that is EPC capable, an SGSN shall do a DNS SNAPTR query for APN resolution.
If this feature is not enabled on the SGSN, the SGSN proceeds with the selection of a GGSN as usual, despite the UE ‘s network capability. Without this feature, whenever a release 9 compliant UE moves from a 2G/3G network to a 4G network, the PDP context has to be deactivated from the GGSN and a new activation towards a PGW is needed.
With this feature enabled, the signaling load on the network side is reduced because the deactivation and activation procedure is avoided when the SGSN selects a PGW during 2G/3G activation.
It is now possible for the operator to configure a reduced priority for LinkManager Control messages, thereby giving timer messages the highest priority. The timer messages are retained at the highest priority and data messages are kept at a lower priority. As a part of this enhancement, a new parameter, sctp-init-rwnd, will enable the SCTP association to maintain a configurable window at the receiving end.
To avoid high traffic levels during PDP establishment, the SGSN has been modified to reduce the attach time, as much as possible, so that the devices can attach and discontinue sending requests. This change is intended to reduce the time needed to retrieve vectors over the Gr interface by allowing the operator to configure the SGSN to start authentication towards the MS as soon as it receives the first vector from the AuC/HLR. With the change to the configuration, the SGSN begins the MS authentication process immediately after receiving the first vector from the HLR, while the SAI continues in parallel.
The attach process may continue in the case of an IMEI check timeout, based on the SGSN service and/or the GPRS service configuration. But the attach only proceeds if the route towards the EIR is up and the IMEI request timer expires.
The software has been enhanced to configure the SGSN to allow the attach process to continue if the route towards the EIR is down, e.g., the DPC / SSN is out of service. This new CLI control command has been added to SGSN service and GPRS service configuration modes.
A file sequence number is a unique number assigned to an individual CDR file. This file sequence number is stored in the aaaproxy and if the aaaproxy restarts or the chassis restarts then the sequence number used to reset. This feature prevents the file sequence number from resetting to zero and recovers the file sequence number so that the number continues to be incremented.
The file sequence number is stored in RAM and whenever a file is transferred from RAM to the hard disk drive (HDD on the SMC), the file containing the latest sequence number is also sent to the HDD.
The custom29 dictionary has been implemented in compliance with 3GPP 32.215 v4.5.0 to provide standard Release 4 format for S-CDRs with all IP addresses in binary format. This implementation follows standards with the following exceptions:
The SGSN now supports both IPv4 or IPv6 formats for the PDP IP address field in the S-CDR using the custom33 dictionary.
To facilitate monitoring and troubleshooting of Gb/FR E1/T1 connections, new CLI output counters have been added to measure the current and high/low watermark counters. As well, a new bulk statistics schema has been added, DLCI-Util, to monitor DLCI utilization thresholds.
In accordance with 3GPP TS24.008, TS23.060, and TS29.060 Release 9.0 specifications, the SGSN now honors MS/UE requests for dual PDP type addressing (IPv4v6) for PDP context association with one IPv4 address and one IPv6 address/prefix.
It is now possible, to configure SGSN support for MS/UE requested dual PDP type addressing (IPv4v6) for PDP context association with one IPv4 address and one IPv6 address/prefix. Once support is configured for the entire SGSN, the operator has multiple configurable options to refine the level of support for dual PDP type addressing:
|
l
|
Disable support at the RNC-level for a specific RNC that either does or does not support this type of addressing.
|
|
l
|
Configure the SGSN to override the MS/UE requested IPv4v6 PDP type, if SGSN does not support IPv4v6, on the basis of APN selection.
|
The SGSN now fully supports empty SCCP Connection Requests and now adds the ability to process intra-RAU/ Detach/Service Request messages after empty CRs.
The SCCP CR messages contain the RNC’s local reference for the particular connection at the SCCP level but not any RANAP payload. Typically, the SCCP CRs will have a max payload of 130 octets with the RANAP-Initial-UE message from the RNC as the only RANAP message in the CR. The payload of the RANAP-Initial-UE can be one of the following:
In situations where the payload exceeds 130 octets, the RNC may send an empty CR followed by the direct-transfer 1 (DT1) message with the actual payload.
To facilitate troubleshooting, the SGSN will capture procedure-level information per 2G or 3G subscriber (IMSI-based) in CSV formatted event data records (EDRs) that are stored on an external server. This feature logs the following events:
Previous Behavior: The SGSN performed GTP protocol user plane (GTPU) path management per remote node. Paths (connection between two endpoints identified by IP addresses) were not monitored individually. In case of GTPU path failure, all PDPs associated with the remote node were deleted.
New Behavior: By default, GTPU path management is now done per path. The SGSN tracks the PDPs towards the GGSN and the RABs towards the RNC on a per path basis. This makes it possible to list all paths towards a remote node and perform path analysis. As well, in case of path failure, only the PDP contexts and RABs associated with the failed path are affected.
By default, the SGSN updates the CAMEL subscription included in the INSERT-SUBSCRIBER-DATA (ISD) messages received from the HLR. While processing the ATTACH request from the CAMEL subscriber, the SGSN checks whether it has a CAMEL service associated with the corresponding service (either GPRS service or SGN service). It drops the ATTACH request if there is no CAMEL service associated with a corresponding service.
Also by default, the SGSN does not allow establishment of a Direct Tunnel (DT) for a CAMEL subscriber. It strictly validates the subscriber against the CAMEL subscription during the Direct Tunnel setup procedure.
This enhancement makes it possible to control the behavior of the SGSN by configuring the SGSN to ignore the CAMEL subscription. This allows the SGSN to successfully complete an ATTACH procedure when there is an ATTACH Request from a CAMEL subscriber and there is no CAMEL service association in the SGSN. As well, during the Direct Tunnel establishment, validation of the CAMEL subscription is ignored to allow the DT to setup when there is no CAMEL service association in the SGSN.
Previous Behavior: The SGSN only handled Suspend messages received for a known MS with a RA configured in the SGSN’s GPRS service configuration. However, the response to Suspend messages received with a 3G RA or unknown RA was to send Suspend-NAK.
New Behavior: Upon reception of Suspend, the old SGSN suspends data transmission towards the UE and typically starts buffering of packets to ensure these packets are not sent towards the RAN node where they might be lost because the subscriber has moved to the coverage of a different SGSN. The SGSN does not initiate Paging for a suspended MS and waits for the MS to send RAU Request/Resume to resume GPRS service.
In accordance with 3GPP TS 23.060 16.2.1.1.1, the SGSN responds to received Suspend messages in the following manner:
|
l
|
Inter-SGSN-Suspend: the SGSN forwards inter-SGSN Suspend Request to the old SGSN (derived using the RA in the Suspend Request), and then sends Suspend-Ack upon receiving Suspend-Ack from the old SGSN.
|
|
l
|
Intra-SGSN-Inter-RAT-Suspend: the SGSN sends SRNS-Ctxt-Request to the RNC upon receiving inter-system Suspend Request, and then sends Suspend-Ack upon receiving SRNS-Ctxt-Response from the RNC.
|
It is now possible to configure the SGSN to allow only one subscriber, at a time, to attach using a fixed random TLLI. While an Attach procedure with a fixed random TLLI is ongoing (that is, until a new P-TMSI is accepted by the MS), all other attaches sent to the SGSN with the same random TLLI, but using a different IMSI, will be dropped by the SGSN’s Linkmgr.
A configurable timer has been implemented on the SGSN (invalidate old-TLLI timer) which will start upon the receipt of an Attach-Complete message with an old random TLLI. This timer will stop once an uplink packet (e.g., an Activation Request message) is received from the attached subscriber with the TLLI allocated by the SGSN. If no uplink packet is received by the subscriber with the TLLI allocated within the configured time (wait-time), the random TLLI mapping with that IMSI is freed and any other Attach Request with the same fixed random TLLI is accepted. No further attaches from the configured fixed-random TLLI are accepted until the timer is either stopped or has expired. In addition, to limit the wait-time functionality to only the fixed random TLLI subscribers, the TLLI list can be configured to control which subscribers will be provided his functionality.
On receiving RANAP messages from the RNC, the SGSN could experience a problem with PDP context establishment if the message is too long. Following a successful Attach, if the SGSN received a SCCP Connection Request with a GMM Service Request message from the RNC, the SGSN might respond with a SCCP Connection Refused for no clear reason. Further investigation revealed that at the RANAP layer the messages contained an Extension item, a Redirect Attempt Flag, and the SGSN reported a decode error while processing this additional octet.
Managing Path Failure Detection due to Restart Counter Change - Behavioral Change
The SGSN now provides the ability to manage GTP-C path failures detected as a result of spurious restart counter change messages received from the GGSN.
When the SGSN detects GTP-C path failure between the SGSN and the GGSN, the SGSN now assumes PDP sessions at the GGSN are lost and the SGSN deactivates those PDP sessions towards the UE with an indication that the UE should activate the PDP session again. Detection is based on receipt of restart counter change values in messages (Create PDP Context Response or Update PDP Context Response or Update PDP Context Request) which can be spurious. Potentially, this scenario can increase traffic within the operator’s network.
Various enhancements have been made to manage the resulting service deactivations and activations which would cause needlessly large bursts of network traffic if the restart counter change messages from the GGSN are erroneous:
|
l
|
New default behavior defined for handling GTP-C path failures detected as a result of erroneous restart counter changes received from the GGSN. See details in the Operator Notes.
|
The SGSN’s optimized network overload protection performs attach-rate throttling to avoid overloading Gr, Gn and Gf interfaces. When enabled, the IMSIMgr throttles the attach rate to a value configured with a new set of queue-size and wait-time keywords.
If the SGSN receives more than the configured number of attaches in a second, then the attaches are buffered in the pacing queue and requests are only dropped when the buffer overflows due to high incoming attach rate. Messages in the queue are processed (FIFO) until they age-out when the queued message's lifetime crosses the configured wait-time. The wait-time and the attach rate decide the optimal size of the queue.
Previous Behavior: If an MS became unreachable or moved into Stand-by, the state of the MS was marked as ‘suspended’ in the BSSGP layer. The SGSN did not initiate Paging so packets for that MS remained in the BSSGP BVC/MS flow control queue until the SGSN received an uplink packet or a new packet for the MS from the GGSN.
New Behavior: Now if the SGSN becomes aware that the MS moves to standby state, due to expiry of the ready timer or due to radio status, the SGSN initiates PS-Paging towards the MS. If the MS responds to the Paging, then the SGSN can resume sending queued packets without waiting for any activity from/for the MS. This results in a reduction of unnecessary queuing of data.
The GMM-SM event logging feature has been enhanced so that the EDR print format is no longer fixed in length. The length is now variable. So, if the MNC has 2 digits then the RAI or OLD-RAI print format does not append a zero “0” which could cause an MNC error. During the GMM-SM event logging, the RAI and OLD-RAI fields in the EDR now have a variable length depending on the number of digits in the MNC. Based on the MNC, the length can now be 15 (xxx-xxx-xxxx-xx) or 14 (xxx-xx-xxxx-xx) characters. For example, if MNC has 2 digits “09” then the RAI or OLD_RAI prints as - xxx-09-xxxx-xx.
When enabled, this feature allows the SGSN to send the Attach Reject for the Attach Request received with a P-TMSI signature mismatch message. This is done, primarily, to avoid the identification of incorrect mapping of P-TMSI/IMSI at the SGSN if the P-TMSI was allocated to a different MS. Enabling this feature allows the SGSN to validate the PTMSI signature present in the Attach Request against the PTMSI-SIGNATURE stored in the SGSN and then the SGSN sends the Attach Reject to the MS if the P-TMSI signature does not match.
This is applicable only for 2G attaches and this configuration forces the operator to enable P-TMSI reallocation during Attach and INTER-SGSN-RAU procedures.
The SGSN now supports the PSC3 limited to PSC2-level capacity. This means the PSC3 in an SGSN currently supports the same number of subscribers as the SGSN with PSC2 cards. No special configuration is required.
Selective Authentication/P-TMSI Reallocation/ P-TMSI Signature Reallocation - Behavioral Change
Previous Behavior: Subscriber event authentication, P-TMSI reallocation and P-TMSI signature reallocation were default functions.
New Behavior: Authentication for Attach Request, Activate Request, Service Request, RAU Request, SMS Request, and Detach Request is now performed selectively and requires operator configuration to enable the functionality. Authentication and P-TMSI reallocation enabling configuration are only applicable when the SGSN’s performance of these functions is optional.
The command structures of the subscriber event authentication, and of the P-TMSI reallocation and P-TMSI signature reallocation have been re-architected to ensure a consistent and more intuitive user experience. As a result, there are now three consistent forms for each command. The functionality is now selective and the configuration forms of the commands now enable the functionality optionally for:
The ‘no’ forms of the commands consistently disable the functionality in the configuration file. The ‘remove’ forms of the commands consistently delete the specified functionality from the call control profile configuration. As these functions are now performed selectively, according to the operator’s configuration in a call control profile, all default forms of these commands have been deprecated.
Authentication and P-TMSI reallocation enabling configurations are only applicable when the SGSN’s performance of these functions is optional.
The software has been enhanced to allow the operator to configure a threshold indicating the minimum number of unused vectors that should be maintained by the SGSN before it initiates a SAI to refill the buffer. With this feature enabled, the SGSN will maintain a specific number of unused vectors at all times. The SAI is initiated when a vector is used up by the SGSN for authentication and the configuration threshold is hit. The SAI initiated, due to this configuration, will be ongoing in parallel to the procedures. This feature changes how many vectors are retrieved from the HLR each time and stored on the SGSN so it should increase performance by decreasing the amount of interaction with the HLR during procedures.
To reduce the impact of handoffs on TCP flows, optimizations (traffic performance optimization – TPO) will be done at the GGSN. The GGSN needs to be made aware of handoffs before handoffs are completed to reduce the interruptions on the data plane.
The old SGSN informs the GGSN about the start of handoff through a self-generated GTPU packet with proprietary private extensions. The GGSN does not treat this packet as an uplink packet but as an indication that handoff is going to occur. The SGSN sends a pre-handoff GTPU notification to a GGSN only if the GGSN has sent a proprietary GTPU message to inform the SGSN of the GGSN's interest in knowing about handoffs. The SGSN does not treat this GTPU message as a downlink packet.
NOTE: This solution works ONLY between ASR 5000 SGSNs running release 12.2 and ASR 5000 GGSNs running release 12.2. This feature is configured and initiated at the GGSN.
Previous behavior: Previously, it was only possible to configure up to 10 zone code lists per Call Control Profile.
New Behavior: The assignment of zone codes has been altered. There is no longer a limit to the number of zone code lists that can be configured per Call Control Profile because the zone code lists are now dynamically allocated based on configuration.
The SGSN zone code lists are configured with the zone-code command in the call control profile configuration mode to create a zone code which lists one or more location areas (LACs) into which a subscriber is allowed to roam. Previously, there was a static limit of 10 zone codes configurable per call control profile. The subscriber may need more flexibility than 10 zone codes per call control profile, however, it is impossible to predict the maximum number required. So the implementation has changed from a static number of zone codes configured per call control profile to an unlimited number utilizing dynamically allocated memory for zone codes defined for call control profiles.
|
l
|
SGSN sends a UGL on a Routing Area Update (RAU)/ Attach Request from an area which is served by a different SGSN number/MAP service/SGTP service. All fallbacks from various services are handled gracefully
|
|
l
|
SGSN sends a UGL upon uplink activity after an HLR reset. Interaction with the next Attach/RAU as uplink activity should then be handled correctly
|
When GMM authentication is skipped, the SGSN and the MS continue to re-use the latest keys exchanged during the most recent GMM authentication procedure. This can result in the SGSN and the MS going out of sync with the CK and IK currently in use. If a mismatch occurs, then the security mode can timeout or be rejected because the MS will not be able to decipher or perform integrity checks on network messages. This can introduce useless signaling in the network.
This feature allows the operator to enable a forced GMM authentication that will either resolve this type of problem or avoid it. As well, operators can configure a frequency of authentication that best meets their needs.
This section provides information for new features for the Web Element Manager (WEM) application in Release 12.0.
The Web Element Manager is now supported on selected Cisco UCS servers running the custom Cisco MITG Red Hat Enterprise Linux (RHEL) v5.5 operating system (OS).
For detailed hardware platform and hard disk drive partition requirements, refer to the Web Element Manager Overview chapter of the Cisco Web Element Manager Installation and Configuration Guide. For installation information, refer to the Cisco MITG RHEL v5.5 OS Application Note.
IMPORTANT: The Cisco MITG RHEL v5.5 OS is a custom image that contains only those software packages required to support compatible Cisco MITG external software applications. Users must not install any other applications on servers running the Cisco MITG v5.5 OS. For detailed software compatibility information, refer to the Cisco MITG RHEL v5.5 OS Application Note. Multiple WEM servers can now be configured as part of a redundant High Availability failover cluster.
Symantec Veritas Cluster software is supported on both Sun servers using Solaris or RHEL operating system and Cisco UCS servers using RHEL.
Refer to the appendices in the Cisco Web Element Manager Installation and Administration Guide for detailed configuration information.
Support for Disabling FTP ESPV Mode in bsserver.cfg File
WEM users now have the option to disable Extended Passive (EPSV) Mode for FTP file transfers of bulk statistic information. By default, WEM uses EPSV mode. To disable ESPV mode, set the FTP_USE_EPSV= field in the WEM server’s bsserver.cfg file to 0.
When a license update operation is performed in the Exec Mode Commands screen, the license update message now specifies the name of the chassis for which the license was updated.
The migrate.tar.gz file, which provided files that performed WEM database backup and restore functions, has been removed as a separate .tar.gz file from the WEM installation package. Instead, the files related to WEM database and restore functionality now are extracted as individual files when the WEM installation .tar file is unzipped. The files include:
The WEM installation script for Red Hat Linux platforms now automatically sets the core file size for the WEM installation to unlimited. This eliminates the need for users to manually set this parameter.
To view the core file size (blocks) setting, navigate to the <ems_dir_name>/server directory on the UCS RHEL server and enter the ./serv status command.
Users based in the United States should ensure that the timezone patch 113225-07 (or later) and libc patch 112874-33 (or later) be installed in support of extended daylight savings time (DST) support.
In addition, if Solaris 9 is used, it must be installed using the “End User System support 64-bit” software group must be specified during the installation of the operating system. This option installs the libraries required for proper operation of the Web Element Manager.
For United States users of Solaris 10 with a Recommended Patch Cluster dated on or after April 2011: Users with Solaris 10 should ensure that the timezone patch 138856-02 or later is installed in support of extended Daylight Savings Time (DST).
Administrators have the ability to hide or display any parent menu and submenu in the GUI as required. This allows the Admin to control what is or is not accessible to the WEM user.
This is controlled by a flag set in the menu.xml file. This file, and an example of how to set the flag, are described in the “Configuration File” appendix in the Cisco WEM Installation and Administration Guide.
Certain patches from Solaris had shown themselves to be unstable There are improvements in stability by installing the following new Patches, documented in the Overview section of the Web Element Manager Installation and Administration Guide:
Solaris 10 with Recommended Patch Cluster dated on or after July 16, 2007 and not later than Nov 2010. Do not install the kernel patch beyond 142900-07.
IMPORTANT: Solaris 10 Kernel patch released between 137137-09 and 142900-04 may result in kernel panic while executing/invoking system calls. Solaris 10 Kernel patch released after 142900-07 has an issue, which will result in failure while invoking WEM Monitor subscriber and Monitor protocol screens.
Previously the Auto Discovery Dialog Box did not discriminate between newly found devices and devices that had been in the database for an indeterminate amount of time, leading to administrative confusion and the possibility of duplication in the database.
The Auto Discovery Dialog Box now supports a new feature where if a discovery is started, only chassis discovered during the latest sweep will be added to the Discovery Result area. If any device discovered during this sweep is already in the database, then a checkbox in the IMGList Added column will be checked. This will prevent the Admin trying to add it twice. If all chassis found during this search have already been added to the database, then all entries will have the checkmark and the Add to IMGList button will be disabled.
For any newly discovered chassis without a checkmark, the Admin can add it to the database using the Add to IMGList button.
Web Element Manager, MUR, PPT and InTracer software can now be co-located on a Cisco UCS server running Cisco MITG Rhel Operating System. This is documented in the MITG RHEL Application Note.
There is a caveat that because WEM and MUR are both processor-intensive, running both on the same server is not recommended.
Certain patches from Solaris had shown themselves to be unstable There are improvements in stability by installing the following new Patches, documented in the Overview section of the Web Element Manager Installation and Administration Guide:
Solaris 10 with Recommended Patch Cluster dated on or after July 16, 2007 and not later than November 2010. Do not install the kernel patch beyond 142900-07.
IMPORTANT: Solaris 10 Kernel patch released between 137137-09 and 142900-04 may result in kernel panic while executing/invoking system calls. Solaris 10 Kernel patch released after 142900-07 has an issue, which will result in failure while invoking WEM Monitor Subscriber and Monitor Protocol screens.
If the superuser password is reset using the script ./set_superuser_password.sh, then on the next login the user is prompted to change the password as the password “superuser” is temporary and does not conform to password strength requirements. After the change, the user can login with the new password.
For further information on ./set_superuser_password.sh configuration, please refer to the Cisco Web Element Manager Installation and Administration Guide.
During a WEM upgrade in cluster mode, the WEM now automatically executes a script that will upgrade all non-database WEM tables. A README file is included with the WEM installer package that provides details about the script’s functionality.
